Page 1 of 2 12 LastLast
Results 1 to 10 of 14

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

  1. #1
    Join Date
    Jan 2007
    Posts
    14,655

    Default 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. #2
    Join Date
    Nov 2008
    Posts
    56

    Default 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.

  3. #3
    Join Date
    Jan 2013
    Posts
    980

    Default

    Hats off to Anchor for this report!!

  4. #4
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,877

    Default

    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)

  5. #5
    Join Date
    Sep 2009
    Posts
    59

    Default 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.

  6. #6
    Join Date
    Oct 2010
    Posts
    91

    Default

    Quote 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.

  7. #7
    Join Date
    Feb 2009
    Posts
    370

    Default

    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.

  8. #8

    Default


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

  9. #9
    Join Date
    Feb 2013
    Posts
    59

    Arrow

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

  10. #10
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    402

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •