Hi all, Here are revisions to the patchset that I sent last Friday, fixing e2fsck failures with filesystems containing the metadata checksumming features. Like last week, e2fuzz helped me to find the failures. The first patch fixes a Coverity complaint against e2fuzz. Patch 2 ensures that e2fsck never clears a block in block_found_map if it's in marked in the block_metadata_map. Patch 3 suggests putting lost inodes in the root directory if it's impossible to recreate the lost+found directory. Patch 4 fixes dumpe2fs to complain about checksum errors without requiring command line options. Patches 5-8 tear down the foundations of the strict_csum vs no_strict_csum patchset in favor of checking any object that fails checksum verification for some basic sanity. If it finds sanity it'll try to recover it, otherwise it'll declare it to be garbage and simply zap it. Users will not have to decide on a config option. Patches 9-12 also fix errors when dealing with FS objects that fail checksum tests. Library flag handling, error reporting, and inode re-checking (for regular mode) all receive some treatment. Patches 13-19 are simple regression tests to check that e2fsck can deal with various kinds of checksum failures -- errors that trigger other corrective action; errors that don't make the FS inconsistent (and would have gone unnoticed without metadata_csu); the checksum itself being wrong; and total block destruction. I've tested these e2fsprogs changes against the -next branch as of 7/29. As I stated in the part 1 introduction, I use several VMs, each with 32M-1G ramdisks to test with; the test process is "misc/e2fuzz.sh -B <fuzz> -s <size>", where fuzz is anything from 2 bytes to "0.1%" of metadata bytes. I've been running five VMs for the past two days, and the only new failures it found resulted in the patches 2-3. Comments and questions are, as always, welcome. --D -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
