Making any fsck checker parallel is fraught with the likelihood that things can go wrong in some setups, with wierd hardwares and with different RAID configurations. XFS have added a prefetch mechanism to xfs_repair which does gives good results in most use-cases but "parallel fsck" is different from "readahead in fsck".
I have a few ideas (scattered, but jotting it down lest I forget them), about having proper parallelization in atleast pass1 (and probably pass2) in e2fsck. Pass1 of e2fsck reads inodes and dumps information into certain data structures, like inode_used_map, block_used_map, directory bitmap, dir block list, etc. Val Henson has recently posted a promising patch which adds readahead threads in pass1of e2fsck where processing of inodes will still be done serially. This does not lend any performance benefits
in a single disk case (though she noted excellent benefits in case of multi-disk RAID arrays).
So coming to the point, I think we can have multiple threads processing on the inodes and dumping information into the pass1 data structures. Contention can be greatly reduced (IMHO made negligible), by having each thread have a cache for each data structure. Each thread can then dump the information into the global shared data structure after its cache is full or after certain time period. This will also speed up e2fsck on single disk machines, as both cores(provided you have a dual-core CPU) can be working parallely.
Another important addition that can be made is to merge read/write requests coming in from different threads, this will especially help reading directory blocks which tend to be scattered around.
But, the fun of all this lies in the implementation, design seems easy enough logically, but implementation would be mired in intricacies. But this seems very interesting to implement.
Chapter 1 of Ansi Common Lisp
3 weeks ago