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
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.