lkml.org 
[lkml]   [2011]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Approaches to making io_submit not block
    From
    Thanks for getting back to me.

    On Mon, Aug 29, 2011 at 10:32 PM, Christoph Hellwig <hch@infradead.org> wrote:
    > On Mon, Aug 29, 2011 at 10:33:24AM -0700, Daniel Ehrenberg wrote:
    >> - Blocking due to reading metadata.
    >> Proposed solution:
    >> Add a per-ioctx work queue to do metadata reads. It will be triggered
    >> from the dio code: if in async mode, then get_block will be called
    >> with an additional flag, meaning something like O_NONBLOCK on sockets.
    >> File systems' get_block functions can implement this flag and return
    >> -EAGAIN if a read from the underlying device would be necessary. (If
    >> we're worried that EAGAIN might be used for other purposes in the
    >> future, we could make a new errno for this purpose.) From a quick
    >> glance at the code, it looks like this would not be too difficult to
    >> add to ext4 for extent-based files, and support in other file systems
    >> could be added gradually. If -EAGAIN is returned, then the struct dio
    >> will be put on the work queue together with a description of what kind
    >> of processing it was doing. The work queue only serves the metadata
    >> request, and the rest of the request is served on the existing path.
    >
    > Let filesystems handle this.  I've actually prototyped it in XFS,
    > based on some pending work from Dave but at this point it's still butt
    > ugly.

    Great, would you be willing to let me see the draft code?

    Are you sure that there wouldn't be any benefit to having the code be
    in the aio/dio levels in terms of making it easier for file
    systems/reducing code duplication?
    >
    >> - Blocking for appends and writes to file holes due to the need for a
    >> metadata write after the data write
    >> Proposed solution:
    >> Maintain a work queue for all appends and writes to file holes, which
    >> executes the current code.
    >
    > No way.  I've fixed this for XFS, and it's trivial without the need to
    > queue them up.  The only thing preventing appending writes to work is
    > a flag to tell the dio layer to just do them, just like it already works
    > for holes.  (and more QA).
    >
    >
    Are you saying this is already fixed for XFS? Appends don't block,
    only reads to metadata do?

    Dan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-08-30 23:53    [W:3.414 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site