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

[phoronix]

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

For a number of years it has been known that the Btrfs RAID5 and RAID6 code is potentially unsafe and not nearly as mature as the native RAID support found in this Linux file-system for other levels. Finally now we are seeing the Btrfs user-space programs warn the user when attempting to create such Btrfs native RAID 5/6 configurations...

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

[vladpetric]

Honesty is good!

I also wish other RAID5 (just 5, not 6) implementations would make users go through a quiz to make sure they understand the trade-offs of RAID5.

Edit: downstream, people convinced me that RAID6 needs a warning these days, too ...

[flower]

Honesty is good!

I also wish other RAID5 (just 5, not 6) implementations would make users go through a quiz to make sure they understand the trade-offs of RAID5.

why not raid6?
iops/performance and rebuild time/risks characteriscs are compareable

[mazumoto]

This is unfortunate ... a few years ago I got the impression that most problems were fixed (beside the write hole). I remember them changing the status for raid56 on their wiki from "experimental" to "mostly safe" or similar.
I actually run a raid5 array of 5 disks for a few years now - because I cannot afford 3 more disks for raid1. So I definitely hope they keep (or start) working on raid56 again

[vladpetric]

why not raid6?
iops/performance and rebuild time/risks characteriscs are compareable

You're absolutely right; I think RAID6 is far less likely to die on rebuild vs RAID5 (at least that's been my experience).

Anyway, I'm totally fine with doing it for both .

[waxhead]

Honesty is good!

I also wish other RAID5 (just 5, not 6) implementations would make users go through a quiz to make sure they understand the trade-offs of RAID5.

Are you thinking of mdraid here? mdraid have closed the write hole just for the record.

I also wish that BTRFS would really stop using the RAID terminology. While it technically is a Redundant Array of Inexpensive Disks it is regardless not what normally is understood as RAID. For example, unlike regular RAID assigning a spare device does not makes much sense in BTRFS terms. If BTRFS supported it , reserving spare space would be the correct way of handling that sort of thing.

[King InuYasha]

Are you thinking of mdraid here? mdraid have closed the write hole just for the record.

This is only true if you're willing to make a dedicated journal device. Otherwise it still has the write hole issue.

[skeevy420]

For the past 20 minutes I've had a BTRFS root with compress-force=zstd:2. It's on a single SSD.

While I prefer the KISS method and sticking to stripes, mirrors, and both (0, 1, 10), I applaud this move because, well, not everyone is going to look up "will XYZ configuration screw me over" when the team leader says "Get moar performance out of the system". Also allows a lower level sys admin to go "Well the tool said not to and you head honchos approved it anyways" when it hits the fan.

[vladpetric]

Are you thinking of mdraid here? mdraid have closed the write hole just for the record.

I also wish that BTRFS would really stop using the RAID terminology. While it technically is a Redundant Array of Inexpensive Disks it is regardless not what normally is understood as RAID. For example, unlike regular RAID assigning a spare device does not makes much sense in BTRFS terms. If BTRFS supported it , reserving spare space would be the correct way of handling that sort of thing.

Ok, good to know, but the main issue I had to deal with is rebuild stress under load (essentially one disc mechanically failing leading to increased stress on the entire array, and causing a second one to fail).

I'm totally fine with BTRFS not using RAID terminology.

[Berniyh]

This is unfortunate ... a few years ago I got the impression that most problems were fixed (beside the write hole). I remember them changing the status for raid56 on their wiki from "experimental" to "mostly safe" or similar.
I actually run a raid5 array of 5 disks for a few years now - because I cannot afford 3 more disks for raid1. So I definitely hope they keep (or start) working on raid56 again

One significant bug is enough to raise a warning in case of filesystems.
Apart from that, while most problems might be (and seemingly are) fixed, it's not as well tested as the other raid levels.
I'm also hoping that in the not-to-distant future btrfs will have the write hole fixed and no other problems came up, because I would like to use raid6 on one my external storage.

But then, since they now have the raid1c3/4 modes and since (big) HDDs are really cheap it's also not that big of a deal anymore.

I also wish that BTRFS would really stop using the RAID terminology. While it technically is a Redundant Array of Inexpensive Disks it is regardless not what normally is understood as RAID. For example, unlike regular RAID assigning a spare device does not makes much sense in BTRFS terms. If BTRFS supported it , reserving spare space would be the correct way of handling that sort of thing.

Maybe, but actually if they were actually using different terms, people would complain about that, too.
In the end, it's just not such a big deal that it's worth discussing it in lengthy ways. :P