Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by cmn32480 on Sunday August 07 2016, @02:38PM   Printer-friendly
from the how-bad-could-it-really-be dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Sunday August 07 2016, @09:57PM

    by Anonymous Coward on Sunday August 07 2016, @09:57PM (#385063)

    crashing an ext4 filesystem by having your seagate harddrive overheat does the same thing.

    And yes I have tried with ext2/3 and the same thing doesn't happen... HOWEVER running ext3 on the ext4 driver DOES cause similiar corruption.

    So now all my archival partitions stay ext2 and only my OS drives end up ext4 (it does offer better performance usually, but the reliability is definitely shite. Plus it is unreliable thanks to feature changes if you ever need to use it in a system with an older kernel! Same deal with ext2 if you aren't careful about mkfs options!) Another issue to be aware of: the ext3 driver breaks on certain options depending on if you're using an i686 vs an x86_64 driver. The ext4 driver will load the i686 formatted partitions on x86_64, but will if you switch to an i686 kernel, whereas the ext3 driver (when still present in the kernel) would load the partition on i686 but fail if you attempted to load it on x86_64 with an invalid filesystem options error. Why is this important? Because it meant either changing the fstab entry before boot, or manually setting the filesystem driver on the kernel commandline to ensure it would boot smoothly. Forget to do it, especially on a remote system, and you end up with your server hung.