On 7/6/20 8:21 PM, Chris Murphy wrote: ... > Yes. Also in fuzzing there is the concept of "when to stop fuzzing" > because it's a rabbit hole, you have to come up for air at some point, > and work on other things. But you raise a good and subtle point which > is also that ext4 has a very good fsck built up over decades, they > succeed today from past failures. It's no different with Btrfs. > > But also there is a bias. ext4 needs fsck to succeed in the worst > cases in order to mount the file system. Really? > Btrfs doesn't need that. > Often it can tolerate a read-only mount without any other mount > option; Well, this assertion can be tested, so let's do that as well; I'll do 50 runs of: * mkfs w/ -m single as would happen on SSD * fuzz 2048 byte of that 1G image at random * mount -o ro, tally mount failures * count missing/unreachable files if mount -o ro succeeds <50 runs later on btrfs> 16 readonly mounts failed (32% failure rate) Within the successful mounts, 1 or more files were unreachable in 30 attempts. Across all 50 attempts, 7720 files were lost. Is that better than ext4, and will ext4 need fsck just to be able to mount? <50 runs later on ext4, same strategy> zero mount failures for ext4. Within the successful mounts, 1 or more files were unreachable in 2 attempts. Across all 50 attempts, 48 files were lost. It does not seem that btrfs has any unique or superior mount -o ro recovery capabilities, either. > and optionally can be made more tolerant to errors while still > mounting read-only. This is a significant difference in recovery > strategy. An fsck is something of a risk because it is writing changes > to the file system. It is irreversible. Btrfs takes a different view, > which is to increase the chance of recovery without needing a risky > repair as the first step. Once your important data is out, now try the > repair. Good chance it works, but maybe not as good as ext4's. That's not supported by any of these test results. -Eric _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
