On Mon, Aug 25, 2008 at 08:50:14PM -0700, david@lang.hm wrote:
Three types:
1. immediate dispatch - merge first with adjacent requests
then dispatch
2. delayed dispatch - queue for a short while to allow
merging of requests from above
3. bulk data - queue and merge. dispatch is completely
controlled by the elevator
Basically most metadata and log writes would fall into category 2,
which every logbufs/2 log writes or every log force using a category
1 to prevent log I/O from being stalled too long by other I/O.
Data writes from the filesystem would appear as category 3 (read and write)
and are subject to the specific elevator scheduling. That is, things
like the CFQ ionice throttling would work on the bulk data queue,
but not the other queues that the filesystem is using for metadata.
Tagging the I/O as a sync I/O can still be done, but that only
affects category 3 scheduling - category 1 or 2 would do the same
thing whether sync or async....
Right, because there was no 'metadata' tagging, and 'sync' happened
to do exactly what we needed on all elevators at the time.
Yeah, I've been saying that for a while w.r.t. the filesystem/block
layer interfaces, esp. now with discard requests, data integrity,
device alignment information, barriers, etc being exposed by the
layers below the filesystem, but with no interface for filesystems
to be able to access that information...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
