Sorting disk I/O requests... [LWN.net]

Sorting disk I/O requests...

Posted Oct 2, 2002 11:49 UTC (Wed) by axboe (subscriber, #904)
In reply to: Sorting disk I/O requests... by Baylink
Parent article: A new deadline I/O scheduler

You cannot say for sure where anything is on a hard drive, but you can make some basic assumptions that generally are true. The assumptions that the deadline io scheduler makes is that:

- Generally, sector x and x+1 are contigous on media.

That is it. I say generally, because x+1 might be remapped due to defects, for instance. But you'll find that in most cases the above is true. Of course drive makers are free to do whatever they want, but general performance breakdown would occur in _all_ os's if a streamed read from LBA 0 to LBA 2048, eg, would incur lots of seeks.

deadline doesn't even attempt to say that a seek from a to b is more or less costly than a seek from x to y.

Maybe you should read the source. I'll bet you it's a lot better source than some 'repairing pcs' book.

(Log in to post comments)

Sorting disk I/O requests...

Posted Oct 8, 2002 2:27 UTC (Tue) by tigerand (guest, #6150) [Link]

This doesn't sound like it takes software raid (md) or filesystem I/O footprints into account. So if either of those two subsystems have any I/O scheduling type optimizations, then these optimizations are almost certainly going to clash with very unsatisfactory results.

It sounds to me like this needs a heck of a lot more thought before it should be truely adopted. Even just sorting between reads and writes could clash with optimizations in some of the fancier journaling file systems. Delayed writes and the like could cloud the algorythm. There really needs to be a way to synchronize between file system code, low level block i/o code, and md code. For instance, I can see this scheme making a huge difference on a single disk with multiple file systems and maybe even a couple of chuckleheads dd'ing to a partition (or, god forbid, a user level file system like Coda or some databases that want to use raw partitions). In that case, a file system might want to wave off it's own optimizations in favor or this. But if it's a single file system on a disk situation, the file system code might know better, especially with it's advanced knowledge about what might be coming just behind this, but isn't in the queue yet. For instance, it knows that right now there are some data writes to accomplish, but right after that there's going to be some journal writes, so save up some pending journal writes just a tad, because there's a couple more just around the corner. This is an example of special knowledge, not a conflicting optimization. But you get the idea.

Bottom line, this seems like a thing that belongs in the file systems, and at the low level is probably the wrong place to "fix" this.