On Wed, Jan 16, 2019 at 12:40 PM Oliver Freyermuth <o.freyermuth@xxxxxxxxxxxxxx> wrote: > Since repair did already run (and did not really help, but segfaults after trying some things) I guess the volume is hosed now anyways. > It's still sad there is no clear explanation for the corruption - I still believe it *might* have been unmounted hard while btrfs-cleaner was running, though, > but I would hope that can not lead to a non-recoverable state (especially if "only" deleted / to-be-deleted subvolumes are affected). Well in theory no, even cleaning is predicated on COW. So what should be true is the trees are pruned and written into a new location, and only once that succeeds is a new super written. Of course, a complicating factor is the tree walking is expensive, likely not all of it can fit in memory at one time, and the new pruned tree isn't all written out at once either; and then another complicating factor is if any new files are being created at the same time. You don't want all new writes to be held up until the cleaning is done. But if there's no hardware fault or transient power problem or failure at the time, then all of this should eventually complete successful and in the proper order. That it didn't, suggests a bug. The problem is where. Btrfs bug? Some other kernel bug? Hardware, including firmware, bug? -- Chris Murphy
