On Mon, Apr 1, 2019 at 6:40 AM berodual_xyz <berodual_...@protonmail.com> wrote: > > Dear all, > > "btrfs rescue chunk-recover" also crashes. I wonder if having this crash > fixed in the tools is preventing me from restoring the filesystem?
The crashing could in fact make the problem worse if it's also writing any changes to disk that are interrupted by the crash. So yeah, until the crasher is fixed, it's not going to improve the situation. >Or maybe manually fixing the data corruption that causes this? I don't understand the question. If you use --init-extent-tree it almost immediately starts writing a new extent tree. And if that's interrupted at all or does not otherwise succeed, the file system is useless for anything else. You'd need to reimage your clones from source. Over on the linux-raid@ list, they do this, which I think also works for LVM. It definitely doesn't work with Btrfs. https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID#Making_the_harddisks_read-only_using_an_overlay_file The reason why is because the overlays and original block devices are indistinguishable to Btrfs. And the user space tools have no way of explicitly specifying the block device. You pick one device, and it uses UUID to infer the rest of the members, and it's uncontrollable which ones it'll pick. If you have a separate computer, you could export only the rw overlays via iSCSI to another computer, and that would likely work. The one thing I'd add to the overlay recipe, is using `blockdev --setro` on all the original drives, just to make certain they aren't written to. It's more than a little frustrating we don't have non-destructive repair on Btrfs. Btrfs has a full volume snapshot via the seed device feature, so a future repair feature could just do that automatically and write out the repair to another volume or to a file. And then that repair attempt could be sanity checked just by mounting the sprout device containing the repaired file system. Even if it's not a perfect repair it might allow a read only mount, and permit normal extraction methods. It would also be better for developers to always have access to the before repair state, and after repair state. But right now we've got numerous cases for a long time of `btrfs check --repair` blowing up file systems worse than they were before the repair was tried, and in the process the file system is so badly damaged it's not even useful for user or developer. -- Chris Murphy
