Messages in this thread | | | Date | Tue, 30 Aug 2011 14:51:01 -0700 | Subject | Re: Approaches to making io_submit not block | From | Daniel Ehrenberg <> |
| |
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/
| |