Am 17.01.19 um 01:28 schrieb Chris Murphy: > 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? > Thanks for the explanation, getting a better understanding of the expected behaviour is really appreciated! I would even add the disk controller's firmware to the list of potential causes - it's an SMR disk (sadly, fully device managed) which does _a lot_ of data shuffling, sometimes slowing down to something like 300 kB/s especially when btrfs-clean runs and does a lot of random access. I have learnt my lesson never to do random writes on device-managed SMR again, but use them as write-once media. In case anybody thinks that providing metadata of the image or extracting more details from it helps to at least exclude / identify a btrfs bug, please tell me. Otherwise I'll purge it in a few days, I have salvaged all data I wanted. Excluding everything else is complex. I know the pain, since I have already (almost) lost one and corrupted another BTRFS volume due to the infamous r8169 bug which has affected hundreds of thousands of machines (and still affects those with old kernels!): https://github.com/torvalds/linux/commit/a78e93661c5fd30b9e1dee464b2f62f966883ef7 It took me years to finally invest enough time to identify the cause of that corruption, since memtests could never show it and I had to actually trigger it from user space by reading network statistics (and only then, a userspace memtest could see it). Cheers, Oliver
