| |||||||||||||
|
| |||||||||||||
What about fsck times???What about fsck times???Posted Jan 26, 2008 20:12 UTC (Sat) by nix (subscriber, #2304)In reply to: What about fsck times??? by giraffedata Parent article: A better ext4
Yes, one of them will be in the right place: but the others will be all over the shop, and the device will have to satisfy those very soon as well, so as to free up space for more requests. It seems to me that this is a quick route to death-by-seeking.
(Log in to post comments)
What about fsck times??? Posted Jan 26, 2008 22:09 UTC (Sat) by giraffedata (subscriber, #1954) [Link] Yes, one of them will be in the right place: but the others will be all over the shop, and the device will have to satisfy those very soon as well, so as to free up space for more requests. If space for requests is the issue, it doesn't matter which requests you satisfy -- they all return the same kind of space. You can ignore the distant requests as long as you want I thought you'd point out that the general purpose head scheduling algorithm stresses response time, so would satisfy those distant requests soon. But fsck doesn't need response time, and should use a head scheduling algorithm that satisfies the near requests first regardless. You can let 990 of those threads wallow while the disk cycles through requests from the 10 that happen to be working in the same region of the disk. I would much rather see the device driver than the application doing head scheduling. Only the device driver really knows the seek issues.
What about fsck times??? Posted Jan 27, 2008 15:16 UTC (Sun) by nix (subscriber, #2304) [Link] 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.
|
|
||||||||||||