User: Password:
|
|
Subscribe / Log in / New account

What about fsck times???

What about fsck times???

Posted Jan 24, 2008 13:51 UTC (Thu) by corbet (editor, #1)
In reply to: What about fsck times??? by alonz
Parent article: A better ext4

The metadata clustering proposal discussed last week would certainly be applicable to ext4. See also Val Henson's e2fsck patch, which I've not had a chance to look at yet.


(Log in to post comments)

What about fsck times???

Posted Jan 24, 2008 16:17 UTC (Thu) by alonz (subscriber, #815) [Link]

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.

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds