A real possibility to speed up fsck is supporting many storage trees per
volume.
This feature has a special name "subvolumes": you marked some directories as
"subvolumes", so that (meta)data of their children will be stored in the
respective
storage tree.
So, instead of processing one storage tree fsck will process many trees
in parallel.
The old name of this feature is "ChunkFS": there were attempts to
organize something
similar in ext3..
Thanks,
Edward.
On 09/20/2013 10:11 AM, Mathieu Belanger wrote:
A build-fs probably read the whole disk to find what it need to
rebuild (I did not check inside but it sound like that). After, if you
add that for reading a fatty 2TB hard drive still go at the speed of a
80GB drive, that will justify the time ;)
So if fsck go read the nodes "one at a time" and that you have
something like a Western digital Grean 2TB, you end up with a nominal
transfer speed of 56.6MiB/s with is about half the max because you
miss one (slow)RPM of read, you end up with 609 minutes and so just to
read the STORAGES TREE nodes...
If fsck read them "one at a time", it could be speed-up by doing a
sequential read of the whole disk and using the ram for buffer to scan
for theses nodes but it's not actually the priority (lot of thing are
more important than the speed of fsck, for exemple FITRIM to keep our
SSD fast).
--
To unsubscribe from this list: send the line "unsubscribe
reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
