| |||||||||||||
What about fsck times???What about fsck times???Posted Jan 24, 2008 16:17 UTC (Thu) by alonz (subscriber, #815)In reply to: What about fsck times??? by corbet Parent article: A better ext4 I'm not sure metadata clustering (and/or parallel fsck) will be sufficient to solve the fsck problems. Metadata clustering is more of an issue for ext3 (which has per-block metadata) than for ext4 (which has extents), and parallel fsck only helps when metadata is split over several disks (e.g. RAID), but not with single huge disks. I had hoped to see is something like (for example) Daniel Phillips' idea in http://lkml.org/lkml/2008/1/13/146: a small change in ext4 metadata format (adding a reverse mapping), which may allow fsck to operate on-the-fly and way faster than it is now. This is (IMO) far more scalable than the other approaches, whose effects are at most linear.
(Log in to post comments)
What about fsck times??? Posted Jan 24, 2008 22:24 UTC (Thu) by i3839 (guest, #31386) [Link] 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.
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.
|
|||||||||||||