[boardwaalk]

As someone who is in the middle of pulling apart a BTRFS volume by hand (read: writing code to interpret the data structures) to try and recover it, I think being burnt enough is once.

No indication of any hardware issue: No recent power loss (& it's on a UPS), no SMART issues, no memory test positives. But the block tree (at least, WIP) is f*cked across all the disks (looks like two competing writers went at it) and none of the available tools can deal with it.

It wasn't a super exotic setup either: RAID10 with 4 disks (2 stripes), fairly full and regular snapshots/cleanup, but that's it.

I already converted my root to ext4 because paranoia and I'm probably going to move bulk data (what can be recovered) to ZFS.

[AshamedCaptain]

This just can't happen with btrfs since the _old_ block tree should be still in the disk somewhere. i.e. to corrupt the image so that btrfs shits itself is easy to do, but the _previous_ version of the data is still there by construction and if you are already manipulating the data structures it should be easy enough to just point the sb to it.

The worst issue I've ever had with btrfs simply required zeroing the journal (by hand -- both the kernel and *fsck tools would crash when reading it). The first time I reported the issue to the mailing list and the underlying issue was promptly fixed. However, it still happened a second time, and I didn't bother reporting it. As many people say on this thread, once is too many when it comes to filesystems.

[stingraycharles]

For what it's worth, about a year ago I had data being corrupted with ZFS (something about NVMe + raidz + dedup if I recall correctly) -- this was fortunately while I was testing deployments, and quickly confirmed as a bug (and fixed) by the ZFS team. But it left me equally burned.

Using xfs|ext4 + mdraid is just a lot simpler and much faster, and it addresses most of my use cases.

[AdamJacobMuller]

I've been there, not with BTRFS but with reiserfs many many years ago. I don't envy you.