Announcement

Collapse
No announcement yet.

The Good & Bad Of Btrfs In A Production World

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • The Good & Bad Of Btrfs In A Production World

    Phoronix: The Good & Bad Of Btrfs In A Production World

    A web hosting company has publicly shared their thoughts on the Btrfs file-system for Linux. While often discussed as the next-generation Linux file-system, Btrfs isn't fully baked for use in a production world quite yet...

    http://www.phoronix.com/vr.php?view=MTM1OTY

  • #2
    What kernel and btrfs-progs?

    With btrfs in active development, you need to be running a leading edge (right now, 3.9.0-rc8) kernel, or patch with the latest btrfs-next and btrfs-progs. A number of the problems they report sound familiar, and have no doubt already been corrected.

    Comment


    • #3
      Hats off to Anchor for this report!!

      Comment


      • #4
        I like the little note they make in their summary...

        btrfs has actually detected single-bit corruption in an underlying hardware RAID volume – that’s a win for data integrity!
        Single-bit corruption is, needless to say, awesome and good job to the btrfs devs for having the capabilities to detect it. Im a very happy btrfs user (home server)

        Comment


        • #5
          Needs a second look

          They didn't care to see if the bugs were fixed already?
          And their solution for hung snapshot tasks was to revert to a filesystem without snapshots?

          My favorite benefit is LZO compression If LZO was forced by default, I think BTRFS would be the default in more places by now as these tests would see great performance & smaller disk usage.

          Comment


          • #6
            Originally posted by snadrus View Post
            They didn't care to see if the bugs were fixed already?
            And their solution for hung snapshot tasks was to revert to a filesystem without snapshots?

            My favorite benefit is LZO compression If LZO was forced by default, I think BTRFS would be the default in more places by now as these tests would see great performance & smaller disk usage.
            what happened to lz4? lz4 should be even better.

            Comment


            • #7
              Pretty nice writeup. I imagine Anchor is at least partially bound to certain Kernel and userspace versions, due to whatever stable Linux distribution they're using for their production systems.

              I've personally found btrfs to be quite stable since the 3.8 Kernel, as well as faster due to things like the "turbo fsync" patch that are now in.

              Comment


              • #8

                Originally posted by mercutio View Post
                what happened to lz4? lz4 should be even better.
                It is in ZFS.

                Comment


                • #9
                  Umm.. BTRFS isn't ready for production environments yet, so why is that company complaining about it?.. BTRFS isn't officially stable yet.. Hell, even I am not going to switch to BTRFS until it is stable, and I am just a normal desktop user with nothing important on my computer.. And I have backups..

                  However, having said that, I think when BTRFS finally IS stable, it will literally be the coolest and best file-system on earth..

                  Comment


                  • #10
                    Originally posted by Baconmon View Post
                    Umm.. BTRFS isn't ready for production environments yet, so why is that company complaining about it?.. BTRFS isn't officially stable yet.. Hell, even I am not going to switch to BTRFS until it is stable, and I am just a normal desktop user with nothing important on my computer.. And I have backups..
                    Then how do you suggest to MAKE it "ready for production environments"? How would you make ANY software ready for anything? At some point you just have to go out and employ it in a real environment. If nobody ever did that, and we all sit on our asses waiting for someone and something to declare something ultimatly stable we'd never get any new software.

                    So kudos to those guys (who btw aren't "complaining" at all!) who did exactly the right thing at the right time. And they ran into some snags and bugs (which they hopefully reported) and shared their experience. As a result we're now one step closer to actually having it ready for production environments.

                    Comment

                    Working...
                    X