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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds