Announcement

Collapse
No announcement yet.

Btrfs File-System Updates For Linux 4.6

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

  • pal666
    replied
    Originally posted by numasan View Post
    I'm curious, what is the advantage of using BTRFS over EXT4 or XFS on the root filesystem?
    rollbacks

    Leave a comment:


  • pal666
    replied
    Originally posted by aksdb View Post
    "not particularly exciting"? The fact that there are not many changes IS exciting. Because that begins to show stability.
    in biology 'stability' means 'death'
    for btrfs it means no online filesystem check for example

    Leave a comment:


  • uid313
    replied
    How much has Btrfs matured the past year(s)?

    How does Btrfs compare against ZFS nowadays?

    Leave a comment:


  • numasan
    replied
    Originally posted by dweigert View Post
    I have something over 5000 instances of BTRFS running as the root filesystem on SLES11 and 12 - on multiple architectures (x86_64 and s390x). Weirdest issues I've seen is people filling it up and wondering what happened...
    I'm curious, what is the advantage of using BTRFS over EXT4 or XFS on the root filesystem? Or is it just because BTRFS is default for SLES?

    Leave a comment:


  • jacob
    replied
    Originally posted by SyXbiT View Post
    Exactly. Developed for nearly 10 years, and most people still wouldn't trust it with their data. I've been hoping for a ZFS competitor for years.
    BTRFS is to ZFS what HURD is to Linux. A research project that aims to be better than the stuff we all use in production, but don't.
    It seems Facebook, at least, does trust it with their data. The BTRFS development process has been a huge fiasco, no question about that, but it still puzzles me that people who dismiss it altogether usually look up to ZFS, which has been stable... on solaris (not to mention its less than stellar design).

    Leave a comment:


  • dweigert
    replied
    I have something over 5000 instances of BTRFS running as the root filesystem on SLES11 and 12 - on multiple architectures (x86_64 and s390x). Weirdest issues I've seen is people filling it up and wondering what happened...

    Leave a comment:


  • SyXbiT
    replied
    Originally posted by waxhead View Post
    BTRFS have been a "playground" for almost a 10 years now,
    Exactly. Developed for nearly 10 years, and most people still wouldn't trust it with their data. I've been hoping for a ZFS competitor for years.
    BTRFS is to ZFS what HURD is to Linux. A research project that aims to be better than the stuff we all use in production, but don't.

    Leave a comment:


  • CrystalGamma
    replied
    Originally posted by waxhead View Post
    And yes, I am aware that btrfs is basically developed like that...
    Well Linux in general is developed like this, not just btrfs … but because unlike e. g. graphics, filesystems are persistent, people have especially high expectations of stability.

    Leave a comment:


  • waxhead
    replied
    Originally posted by Ericg View Post

    It also means no FS-level encryption and no dedup work. Both of which are features that a lot of people are looking forward to.
    True, but I think more people are looking forward to having something a bit more stable soon. BTRFS have been a "playground" for almost a 10 years now, and while horror stories about dataloss for single disk filesystem and raid1 are starting to get rare there are still a few weird ones on the mailing list.

    People who are mildly paranoid about the integrity of their data are naturally drawn to filesystems like BTRFS. I do have a 16 terrabyte ext4 filesystem running on mdadm6 and for that reason alone I don't subscribe to either the ext4 or mdadm mailinglists

    I do subscribe to the BTRFS mailing list tough and from what I have seen so far, including my own tests raid5/6 is in a pretty horrific state. I have tested on a 10x 8GB USB memory stick RAID and with mdadm I have not been able to destroy any raid5 or raid6 array. I Have corrupted data, but never lost an array. With BTRFS I did easily corrupt data AND destroyed the array in minutes (only tested on kernel 4.2 and below)

    So at least for me a non-exciting change log for the kernel means less features, more fixes, and I feel pretty confident that I think the priorities for BTRFS now should be prioritized something like this:

    1. Array recovery and reconstruction
    2. Filesystem recovery and reconstruction
    3. Data recovery and reconstruction
    4. Raid1
    5. Raid5/6
    6. "Raid" with n parity devices
    7. Performance
    8. "online" deduplication
    9. encryption
    10. other features

    For the BTRFS devs it should also be benficial to get the basics as stable as possible. Why? because if raid1 for example is declared stable more people will use it. When more people use it you get a broader user base. When the users stop yelling at "stable" features the devs can start add other fancy stuff. As they add stuff, the broader the use base will be and the more people will test new things and yell if they don't work... when all the yelling is reduced to a single person clearing his throat I think we have a pretty stable filesystem.

    And yes, I am aware that btrfs is basically developed like that.... reliability should always come first in my opinion.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by aksdb View Post
    "not particularly exciting"? The fact that there are not many changes IS exciting. Because that begins to show stability.
    No it's not exciting: I would like proper RAID 5 without write hole

    Leave a comment:

Working...
X