openSUSE's YaST Now Supports Multi-Device Btrfs Setups

[phoronix]

Phoronix: openSUSE's YaST Now Supports Multi-Device Btrfs Setups

SUSE/openSUSE continues embracing the Btrfs file-system and now their YaST installer/manager can deal with multi-device Btrfs configurations...

http://www.phoronix.com/scan.php?page=news_item&px=SUSE-YaST-Btrfs-Multi-Device

[jpg44]

This is an enormously powerful and useful feature to handle the need for larger filesystems over many devices and also allow additional space to be added to existing filesystems by adding new hard drives to the existing filesystem. This makes openSUSE the premiere Linux distribution and the most powerful industrial grade Linux distribution out there.

[DrYak]

small note:

"various RAID levels supported by BTRFS"

that would be RAID 0 and 1. Remember that 5 and 6 aren't considered stable yet.



To quote the Yast team from the comments on their blog post:

No, we don’t consider RAID 5/6 in Btrfs to be “enterprise ready”, so to speak. If you look to the screenshot illustrating the creation of a new Btrfs you will notice YaST only offers “single”, “dup”, “RAID0”, “RAID1” and “RAID10” as possible RAID levels.

Raid 5 and 6 are technically implemented in some of the tools offered by the distribution and they can be used. But you will have to use the native Btrfs tools to configure it, instead of YaST.

Those Btrfs RAID levels are not officially supported in SUSE Linux Enterprise, which means if you use them you are basically on your own. Of course, it’s also available in openSUSE Tumbleweed and Leap, but with the same level of stability (that is, use it at your own risk)

[jpg44]

small note:

"various RAID levels supported by BTRFS"

that would be RAID 0 and 1. Remember that 5 and 6 aren't considered stable yet.



To quote the Yast team from the comments on their blog post:

How important is Raid 5/6 when the filesystem supports checksummed blocks which are used along with RAID 1 ? That is, the checksum would catch errors in a block?

[duby229]

How important is Raid 5/6 when the filesystem supports checksummed blocks which are used along with RAID 1 ? That is, the checksum would catch errors in a block?

Nope, because of snapshots... If the FS gets balanced all bit errors get duplicated in a single copy so that -all- snapshots contain the error -with- a valid checksum, so btrfs never recognizes the bit errors. It happens on btrfs with -all- RAID levels. Just that RAID5/6 is more buggy and it causes balancing the FS to duplicate bit errors more aggressively. The only thing you can do is wait for the corrupted data to trigger some sort of bug.

[andreano]

YaST, zypper and OBS are three good reasons to use OpenSuse that other distros should consider reusing.

[DrYak]

How important is Raid 5/6 when the filesystem supports checksummed blocks which are used along with RAID 1 ? That is, the checksum would catch errors in a block?

yes, checksum can catch bitrot errors, and for RAID 1, support is correctly wired in to retry with an alternative copy. (so it should be resilient to non-drive-failure, just like RAID 6)

the importance of RAID 5/6 is space saving:
a N disk raid6 system lets you lose *any* two *random*, so you can have N-2 disks worth of data.

to achieve the same in RAID1 you need to keep everything in triplicate copies (which, btw, isn't currently an accessible setting on BTRFS, yet. btrfs' raid1 stripes are fixed to a suze of 2), which means you're limited to N/3 disks worth of data.

with example numbers, using 6 HDD of 4TB each:
- RAID6 gives you 4TB*(6 - 2) = 16 TB in total.
- RAID1 in triplicate gives you 4TB * 6 / 3 = 8 TB.

(for the "lose 1 drive max" use case, RAID5 would give: 20TB, whereas RAID1 in duplicate gives you 12TB).

so for large file servers the difference is noticeable.

[DrYak]

Nope, because of snapshots... If the FS gets balanced all bit errors get duplicated in a single copy {...}

you're aware that Btrfs checksums *everything*, are you?

any data corruption will nearly(*) always trigger a read error, *will* be detected in a "scrub" operation, and *will* cause a "balance" operation to abort.

(*) - and the chances of a corruption to still producing the *exact same* checksums are low (though not as low on the CRC32 algo used by BTRFS, as on a modern optimized checksum like xxHash64 or on a cryptographic hash like SHA2 - still it would be an extremely uncommon fringe case).

the more i'm reading your anti-btrfs comments, the more it looks to me that you're doing something terribly wrong

(like using it on dying hardware)

[duby229]

@duby229:

you're aware that Btrfs checksums *everything*, are you?

any data corruption will nearly(*) always trigger a read error, will be detected in a "scrub" operation, and will cause a "balance" operation to abort.

(*) - and the chances of a corruption to still producing the *exact same* checksums are low (though not as low on the CRC32 algo used by BTRFS, as on a modern optimized checksum like xxHash64 or on a cryptographic hash like SHA2 - still it would be an extremely uncommon fringe case).

the more i'm reading your anti-btrfs comments, the more it looks to me that you're doing something terribly wrong

(like using it on dying hardware)

It's well documented. PLus, just about anybody can test it, it's btrfs scrub itself that doesn't catch bit errors and is the root cause for the RAID5/6 bugs and why balance always duplicates bit errors. It doesn't checksum -files-, it checksums -blocks- and that is where the root cause of this major flaw really is. The checksums it assigns can be valid even if there are bit errors and then balance duplicates those errors.btrfs major flaw is that the way it lays data out on the disk isn't stable and causes it to give valid checsums to corrupted data and then it even goes the next step further and duplicates the corrupted data for -every- snapshot....

[starshipeleven]

small note:

"various RAID levels supported by BTRFS"

that would be RAID 0 and 1. Remember that 5 and 6 aren't considered stable yet.

RAID10 is a thing