Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Btrfs Will Finally "Strongly Discourage" You When Creating RAID5 / RAID6 Arrays
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Btrfs Will Finally "Strongly Discourage" You When Creating RAID5 / RAID6 Arrays

https://phoronix.com/scan.php?page=news_item&px=Btrfs-Warning-RAID5-RAID6

I use ZFS because of issues like these. no regrets.

Thanked by 1that_guy

Comments

  • Then you have not been reading the stories of losing ZFS arrays.

  • darkimmortaldarkimmortal Member
    edited March 2021

    The ‘bug’ (more incomplete implementation) with raid 5/6 is well known at this point, and raid 5/6 are a dying breed with modern large disks. Doesn’t seem like a particularly good reason to choose ZFS.

    It’s an interesting situation where the public perception might be better if they didn’t support raid 5/6 at all. You see the same thing in video games, developers intentionally nerf capabilities so that people can feel better about themselves when their systems can run games on Ultra.

    If you want a good reason to think twice about BTRFS, the ‘bug’ with BTRFS raid in conjunction with nodatacow/chattr +C is at least as bad and less well known.

    At present, nodatacow implies nodatasum; this means that anything with the nodatacow attribute does not receive the benefits of btrfs' checksum protection and self-healing (for raid levels greater >= 1); disabling CoW (Copy on Write) means that the a VM disk image will not be consistent if the host crashes or loses power. Nodatacow also carries the following additional danger on multidisk systems: because nodatasum is disabled there is no way to verify which disk in a two disk raid1 profile volume contains the correct data. After a crash there is a roughly 50% probability that the bad copy will be read on each request. Consequently, it is almost always preferable to disable COW in the application, and nodatacow should only be used for disposable data

    Source: https://wiki.debian.org/Btrfs

    And I say this as a happy btrfs user - great filesystem when you know its limits, and I prefer its design and tools to ZFS. I’m a bit surprised they chose to advertise the well known raid 5/6 issue and not the less well known raid+nodatacow issue

  • there should be no other raid then raid 10.

    Thanked by 11gservers
  • @TimboJones said:
    Then you have not been reading the stories of losing ZFS arrays.

    I have not most what iv heard is ZFS updating but DKMS module is lagging behind and causing issues.
    or where people use the FUSE module

    My oldest array is 5ish years strong now. no hickups besides updating.

  • Do many people even use software RAID5 or 6? I thought people that use those RAID levels primarily use hardware RAID...

    @darkimmortal said: the ‘bug’ with BTRFS raid in conjunction with nodatacow/chattr +C is at least as bad and less well known.

    Why would someone use a copy-on-write file system and then explicitly disable copy-on-write? 🤔

  • XsltelXsltel Member, Host Rep

    @Daniel15 said: hardware RAID

    they fail and fail so hard to the point you won't find a controller to replace them. hardware RAID left a very bad taste in my mouth a few months ago.

  • @notarobo said:
    there should be no other raid then raid 10.

    Isn't the whole idea behind striped arrays is the ability to lose any n drives where n is the number of drives being used as striped storage.

    Raid 10 if you lose the wrong pair of drives the data becomes lost.

    Wouldn't it be better to be able to lose 2 any drives?

Sign In or Register to comment.