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

What about fsck times???

What about fsck times???

Posted Jan 24, 2008 22:52 UTC (Thu) by nix (subscriber, #2304)
In reply to: What about fsck times??? by i3839
Parent article: A better ext4

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.)


(Log in to post comments)

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