SoylentNews is people
SoylentNews
The nice feller over at phoronix brings us this handy to have bit of info:
It turns out the RAID5 and RAID6 code for the Btrfs file-system's built-in RAID support is faulty and users should not be making use of it if you care about your data.
There has been this mailing list thread since the end of July about Btrfs scrub recalculating the wrong parity in RAID5. The wrong parity and unrecoverable errors has been confirmed by multiple parties. The Btrfs RAID 5/6 code has been called as much as fatally flawed -- "more or less fatally flawed, and a full scrap and rewrite to an entirely different raid56 mode on-disk format may be necessary to fix it. And what's even clearer is that people /really/ shouldn't be using raid56 mode for anything but testing with throw-away data, at this point. Anything else is simply irresponsible."
Just as well I haven't gotten around to trying it then.
(Score: 2) by darkfeline on Sunday August 07 2016, @09:02PM
For a different anecdotal viewpoint, I have been using BTRFS (without RAID) for six months now and have had zero issues, with constant writing and deleting of large media files with LUKS encryption.
Join the SDF Public Access UNIX System today!
(Score: 5, Interesting) by rleigh on Sunday August 07 2016, @09:34PM
This is a "relatively safe" mode of operation, since you're not using any of the RAID code, and it's also much better tested in this mode. But, the thing with filesystems is that it's all fine when there are no problems, since if there are no faults you're not exercising any of the failure codepaths. The true test is when you have hardware glitches on the disk, faulty connectors, or memory errors etc. It's these failure codepaths which are where Btrfs fails so spectacularly, the very parts we absolutely require to work correctly. And having been exposed to a whole bunch of them, I can tell you right now that it's unsuitable for production use if you really care about your data, because relying on Btrfs is like playing Russian roulette! Lightweight use will *seem* OK, and for the most part *will* be OK. Start loading it with multiple parallel users, concurrent snapshots, and it will fail *really* quickly: total time from clean new filesystem to broken and unbalanced for me, the record is: every 18 hours with a few tens of concurrent snapshots and jobs. This is utterly thrashing the filesystem, so with lighter use that time will be significantly more than 18 hours: a week, several months or several years. But the fact that it will simply stop working at some undefined future point is absurd. That's not hardware related; it's a massive design and implementation *fail*. I can thrash an ext3, xfs or other "simple" filesystem in a similar manner for *years* with every expectation that it will continue to work absent any hardware problems. Filesystems demand perfection in their implementation more than any other piece of software; we entrust them with our data. Btrfs has failed at this, badly, ever since its creation. I've been using it since the start. We hoped it would stabilise. It didn't. It's still not trustworthy, and "no issues for six months" really means little when you look at the shocking flaws in it.