Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 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: 5, Informative) by NCommander on Sunday August 07 2016, @02:54PM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Sunday August 07 2016, @02:54PM (#384973) Homepage Journal

    btrfs amazes me in the fact its a pile of crap that has been in development for almost a decade. It's the Duke Nukem Forever of filesystems.

    To put this in context, ZFS development was started in 2001, and shipped in 2005, and at the time of its release, ZFS was likely the most advanced filesystem in the world. btrfs on the other hand manages to be NIH to a horrifying extent (Oracle owns ZFS and is also the chief contributor to btrfs), and manages to fuck its strengths.

    On the fly conversion of RAID levels is supposed to be a killer feature of btrfs. To hear its not only broken, but broken to the extent that the on-disk format needs to change well. That's a lot of fail.

    --
    Still always moving
    Starting Score:    1  point
    Moderation   +3  
       Flamebait=1, Insightful=1, Informative=3, Total=5
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 4, Interesting) by Post-Nihilist on Sunday August 07 2016, @03:43PM

    by Post-Nihilist (5672) on Sunday August 07 2016, @03:43PM (#384987)

    The number of paid full time engineer working on ZFS was borderline ridiculous1 Compared to ZFS, brtfs is resources starved since the development started. It's no wonder that they are progressing so slowly...

    1-I knew this as I was working as a campus ambassador for SUN at that time. My job was to shill for SUN by giving OpenSolaris DVD and T-Shirt and organizing technical talk with SUN's engineers. But most importantly, the job was about filling reports about filling reports for 4 different managers. It is no wonder that SUN imploded on its own mass just before getting sold to Oracle....

    --
    Be like us, be different, be a nihilist!!!
    • (Score: 4, Interesting) by NCommander on Sunday August 07 2016, @05:15PM

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Sunday August 07 2016, @05:15PM (#385003) Homepage Journal

      Sun's management was famously clueless. I've liked how the (in)famous USENIX talk on the subject, https://www.youtube.com/watch?v=-zRN7XLCRhc [youtube.com] which had a rather epic rant on the subject, describing the situation akin to Somalia warlords.

      That being said, I miss Sun. I rather deal with incompetence vs. malice, and that's about the best way I can describe Oracle's practices. At leas Sun both gave back, defined open standards, and from a technical standpoint, pretty damn decent.

      --
      Still always moving
      • (Score: 3, Interesting) by Post-Nihilist on Sunday August 07 2016, @07:01PM

        by Post-Nihilist (5672) on Sunday August 07 2016, @07:01PM (#385021)

        Sun's management was well past the cluelessness point, they were deep into the Kafka zone. When I got bored by that chearleading job, I did a small experiment: Instead of quitting I kept submitting reports on how i spent my time fillings the report requested by the other managers, naively thinking that they would catch on the silliness of the situation. I was so naive...all I managed to achieve is getting some praise for my accurate record keeping, at which point I formally resigned.

        --
        Be like us, be different, be a nihilist!!!
      • (Score: 3, Insightful) by fleg on Monday August 08 2016, @04:13AM

        by fleg (128) Subscriber Badge on Monday August 08 2016, @04:13AM (#385158)

        >Sun's management was famously clueless.

        i was there in the late 80's/early 90's in the uk, they were fine up until around the time they merged their uk and european headquarters into one building, suddenly there were managers everywhere and it went downhill fast in terms of culture. it was also around that time they unbundled the c compiler from the OS, which a lot of the old hands were very unhappy about. i think the writing was on the wall from that point.

        • (Score: 2) by Post-Nihilist on Monday August 08 2016, @04:43AM

          by Post-Nihilist (5672) on Monday August 08 2016, @04:43AM (#385168)

          Let's have a drink to a decade of driftings managers

          --
          Be like us, be different, be a nihilist!!!
          • (Score: 2) by fleg on Monday August 08 2016, @05:29AM

            by fleg (128) Subscriber Badge on Monday August 08 2016, @05:29AM (#385182)

            mines a large single malt!

            does the underbelly of your ivory tower have a bar?

    • (Score: 3, Funny) by driverless on Monday August 08 2016, @06:23AM

      by driverless (4770) on Monday August 08 2016, @06:23AM (#385201)

      It is no wonder that SUN imploded on its own mass just before getting sold to Oracle....

      So Oracle essentially bought a neutron star?

  • (Score: 4, Funny) by Anonymous Coward on Sunday August 07 2016, @05:00PM

    by Anonymous Coward on Sunday August 07 2016, @05:00PM (#384998)

    btrfs- "I Can't Believe It's Not Better"®

    Well actually I can... ;)

    • (Score: 0) by Anonymous Coward on Monday August 08 2016, @10:32AM

      by Anonymous Coward on Monday August 08 2016, @10:32AM (#385245)

      I always read "bitrot-filesystem"...

  • (Score: 4, Interesting) by Marand on Sunday August 07 2016, @05:54PM

    by Marand (1081) on Sunday August 07 2016, @05:54PM (#385007) Journal

    (Oracle owns ZFS and is also the chief contributor to btrfs)

    Sounds like this might be part of the problem. Oracle started Btrfs in 2007, then acquired Sun (and ZFS) in 2010. Once Oracle became the owner of the filesystem they were trying to ape, what reason was there to continue putting heavy development into Btrfs?

    Sure, Oracle kept some token effort going on there, but the incentive to make it usable for their needs died once they became owner of the filesystem they were trying to ape, and most everyone else seems to be fine using ZFS, ext3/4, or one of the others like XFS.

    • (Score: 1) by Francis on Sunday August 07 2016, @09:33PM

      by Francis (5544) on Sunday August 07 2016, @09:33PM (#385050)

      Apart from the nutters that insist upon using draconian licensing schemes to control developer behavior, was there every really any point to the filesystem? It seems to me that the problem with Linux filesystems isn't that there are too few of them, but that there's so many that they often times aren't completed before being incorporated. I'm still allergic to EXT4 because when I first tried using it, it would eat the entire install if the system crashed. And the system crashed every time I loaded it, so I'd have to reinstall every single time I'd want to use it.

      Needless to say, I stopped using it and avoid it like the plague, but having a ton of filesystems available that aren't necessarily read for primetime isn't really a good idea. On some level if a filesystem isn't production ready after a certain number of years, it's probably not going to be ready ever. Either it's too niche to attract developers or it's gone off the rails by trying to do too much.

      • (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.

      • (Score: 2) by Marand on Sunday August 07 2016, @11:10PM

        by Marand (1081) on Sunday August 07 2016, @11:10PM (#385077) Journal

        Apart from the nutters that insist upon using draconian licensing schemes to control developer behavior, was there every really any point to the filesystem?

        It started inside Oracle, so the reasoning was probably as simple as "Oracle wanted ZFS but Sun has it." No idea why they didn't just abandon ship as soon as they bought Sun, though; maybe a passionate dev in the company convinced someone to keep working on it fort he future or something.

        The appeal for others was either "ZFS licensing isn't compatible with the Linux kernel but we want ZFS features" or "we want stuff that ext[2|3|4] doesn't have", but it's apparently not been enough. It may well be a good long term goal, and if that's what someone wants to work on good for them, but it still isn't ready for everyday use and I'm amazed people actually suggest it for such. :/

        I've got nothing against developing new filesystems, and I don't think it's a problem that the kernel supports a bunch of niche ones, because use cases are different and sometimes a good specialised FS isn't suitable for general use (or vice-versa). The problem here with btrs is that filesystems are too damn important to put into production use when still immature, and for whatever reason people seem to think it's production-ready when it's clearly not.

  • (Score: 3, Flamebait) by Entropy on Sunday August 07 2016, @09:38PM

    by Entropy (4228) on Sunday August 07 2016, @09:38PM (#385052)

    ZFS has everything BTRFS has, but in a vastly superior interface. Last I checked each snapshot in BTRFS needed to be mounted(why?) making your mount screen look like a tragedy. Also writable snapshots? Why would I ever want to write to a snapshot?! The point of a snapshot is it's frozen.

    Of course ZFS has had a superior version of raid5 forever now, block level replication based on snapshots, and physical devices(zvols) that can be used as virtual machine hard disks.(that can also be replicated!)

    No doubt BTRFS could one day achieve all those things, of course...but that day is far in the future.