Be sure to read the whole thread, starting here.
So it sees the data strip corruption, uses good parity on disk to fix it, writes the fix to disk, recomputes parity for some reason but does it wrongly, and then overwrites good parity with bad parity
tl;dr - there’s a serious bug in the btrfs RAID 5/6 parity calculation code.
does anyone else run btrfs? I had a good experience with btrfs + snapper snapshot utility for rolling back package breakages etc, but had to switch away because of disk usage (I have a very small hard drive)
I used it for a while on a single disk (SSD) workstation system as an experiment. It worked ok but all of the warnings online and the frequent near-horror-story posts on the mailing list put me off. All of my larger Linux systems are still XFS/XFS+mdraid but I’m in the slow process of transitioning to ZFS on Linux where appropriate (embedded systems will remain ext4).
I don’t mean to sound critical, but for all the work that’s been put into it, btrfs doesn’t seem to be any closer to production-ready than it was 4-5 years ago. Filesystems are far from trivial, but as a counterpoint DragonFly BSD was able to deliver production-ready HAMMER in far less time with fewer developers and at this rate it looks like HAMMER2 will be ready before btrfs.