Results 1 to 10 of 16

Thread: SUSE Enterprise Considers Btrfs Production Ready

Hybrid View

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

    Default SUSE Enterprise Considers Btrfs Production Ready

    Phoronix: SUSE Enterprise Considers Btrfs Production Ready

    SUSE is now comfortable officially supporting the Btrfs file-system and considering it a "production ready" Linux file-system...

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

  2. #2
    Join Date
    Sep 2008
    Posts
    89

    Default

    Meanwhile, if you visit Oracle's btrfs page, you're greeted with this bolded information:

    The Btrfs disk format is not yet finalized, and it currently does not handle disk full conditions at all. Things are under heavy development, and Btrfs is not suitable for any uses other than benchmarking and review.
    I suppose that's outdated, but that's bad enough.

  3. #3
    Join Date
    Sep 2011
    Posts
    40

    Default

    On the same page:
    The Btrfs pages have moved to http://btrfs.wiki.kernel.org, please visit the new site to find documentation, downloads and more details on Btrfs.

  4. #4
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,538

    Default

    I suppose it's about time. The btrfsck tool is still a bit hit-and-miss with whether it introduces new issues while fixing or not, but then you are not likely to hit any real issues with it unless you have a faulty RAM module (which I had, unfortunately, but Btrfs remained bootable and all the personal data was still intact even under those circumstances). So while not the default option, having it as an alternative is good enough now.

  5. #5
    Join Date
    Feb 2011
    Posts
    50

    Default

    I use btrfs for a few years now on all my systems (server, desktop, laptop), I use it on dm-crypted raid5, I use it as root-fs. And I never had any data loss (where ext4, on a rc-kernel, but already stable, ate some of my data). Not even when it was really experimental and really didn't have any out-of-disk handling - I hit that of course :-)
    So yeah, it's not statistically valid, but for me it is production ready.

  6. #6
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,538

    Default

    Yea, same here, I used it from the very first version of openSUSE that allowed using it at install time, and had only minor difficulties that do not depend on the FS to begin with. Though I'd really wish YaST would have LVM-like support for subvolumes, right now they are underutilised...

  7. #7
    Join Date
    Dec 2012
    Posts
    4

    Cool

    Quote Originally Posted by mazumoto View Post
    I use btrfs for a few years now on all my systems (server, desktop, laptop), I use it on dm-crypted raid5, I use it as root-fs. And I never had any data loss (where ext4, on a rc-kernel, but already stable, ate some of my data). Not even when it was really experimental and really didn't have any out-of-disk handling - I hit that of course :-)
    So yeah, it's not statistically valid, but for me it is production ready.
    Anecdotal experiences can be deceiving, that's true. This being said, when I tested brtfs out a while ago, I experienced catastrophic data loss. A combination of LVM and LUKS killed it, at least that was my hypothesis at the time. It was perhaps too soon to expect it to survive such scenarios.

    I was running tests and the data was there to be shredded, so no actual loss. I plan to do another round of testing sometimes in the 3.7 - 3.8 period... Is it ready to be used in production? I couldn't tell right now. Some distros seem to think it is, I'm not that convinced. With good, often made and actually restorable backups... and with enough time to do the restore... why not. I'm just afraid that people will start using it without backups. Than again, fsck and related tools could probably use more suck... ehm... testers.

Posting Permissions

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