| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
What about fsck times???
What about fsck times???
Posted Jan 24, 2008 22:24 UTC (Thu) by i3839 (subscriber, #31386)In reply to: What about fsck times??? by alonz
Parent article: A better ext4
fsck is seektime bound, so doing parallel fsck would at least throw more Io requests at the harddisk, making it hopefully seek less on the whole. Or something like that.
(Log in to post comments)
What about fsck times???
Posted Jan 24, 2008 22:52 UTC (Thu) by nix (subscriber, #2304) [Link]
It seems to me that parallelizing, without substantial locking (-> serialization) or very clever design, is likely to *reduce* correlations between block requests and thus *increase* seeking substantially: and if you're adding enough locking to keep correlations between block requests, you can probably make the whole algorithm a serial one without much difficulty. Certainly the naive implementations (e.g. multiple threads, one per block group) would hugely increase seeking. (There's lots of unavoidable serialization too: e.g. you can't carry out the passes all at once, or in a significantly different order.)
What about fsck times???
Posted Jan 25, 2008 19:48 UTC (Fri) by giraffedata (subscriber, #1954) [Link]
It seems to me that parallelizing, without substantial locking (-> serialization) or very clever design, is likely to *reduce* correlations between block requests and thus *increase* seeking substantially
You just need enough threads. If there are 1000 threads, you'll have about 1000 requests in the device's queue at any time, and one of them is bound to be near where the head is now.
I don't know much about fsck; maybe the work can't be done with enough threads to do better than today's single thread.
What about fsck times???
Posted Jan 26, 2008 20:12 UTC (Sat) by nix (subscriber, #2304) [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. It seems to me that this is a quick route to death-by-seeking.
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.