On Wed, Mar 27, 2019 at 7:03 AM berodual_xyz <berodual_xyz@xxxxxxxxxxxxxx> wrote: > My questions now: > > * what is the chance of "btrfs rescue" "chunk-recover" / "super-recover" / "zero-log" having a positive effect on the filesystem. > > * what is the chance of "btrfs check --init-extent-tree" fixing the described issues? You are using btrfs-progs 4.20.2 and it crashes doing a `btrfs check`. That's a significant bug. That tool shouldn't crash, so it already means the file system is in an inconsistent state that btrfs-progs hasn't seen before, and it gets so confused that it crashes. I have 0% confidence that any repair that writes changes to the filesystem will succeed, and better than 99% confidence that it will crash in the middle of a repair and absolutely make the file system non-recoverable. All of the repair options you listed above write changes to the file system, also add `btrfs check --repair` to that list. So until you get advice from a developer, you're sitting on that file system. *shrug* In the meantime, your best bet is a combination of 'btrfs restore' and mounting with `-o ro,nologreplay,usebackuproot`. Once those fail to get you anywhere you're basically stuck, as that's the limit of the repair tools at this point. You could also in the meantime do a scrub on all of the raid6 arrays, and whatever other diagnostics or repairs the hardware raid offers. They *should* recover properly on their own, but... And then also in the meantime, prepare for having to rebuild this array. -- Chris Murphy
