What about fsck times???

It's not just that the general-purpose head scheduling algorithm stresses 
response time: it's also that it has finite storage, so will *have* to 
satisfy even distant requests fairly fast if it's not to starve userspace 
of memory (at least, this is true with the volume of distant requests a 
naively-threaded fsck would generate).

Also, it doesn't `really know' the seek issues. The only circumstance in 
which it knows *any* more about seek issues than fsck is if you're fscking 
a device atop a dm or md device: and in both of those cases the simple 
rule of thumb `issue contiguous requests' will provide far more speedup 
than the block scheduler ever could wring out of a pile of non-contiguous 
requests.

The only thing that really knows the seek issues is the drive controller 
itself (which is possibly remote from the machine doing the fscking), and 
it *really* doesn't have much ability to accumulate large numbers of 
requests and answer them out of order.

The best approach for speed here remains `issue contiguous requests', 
which is of course interesting to balance with fsck memory consumption... 
of course Val knows all of this far better than do I, and now I look at 
the patch she's catered for this, with I/O parallelized such that 
individual block devices *don't* see heaps of seeks.