Live data from Hacker News

Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

phoronix.com

31–40 of 231 posts

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#31
post #9

Glad to see Btrfs getting continual updates. It's my favorite filesystem for my personal machines (work and home PCs). The feature set is just awesome. I just hope it doesn't get completely abandoned as its development seems to have slowed significantly. The only thing it's missing before I consider it full-featured is stable RAID 5/6. But it looks like that hasn't been forgotten.

> The only thing it's missing before I consider it full-featured is stable RAID 5/6. But it looks like that hasn't been forgotten. I've been running BTRFS RAID6 since 2016 and have only had one issue (arch kernel needed to be rolled back) and never suffered anything catastrophic. It's perfectly happy humming along with a 15x8TB raid array.

Are you using Raid6 for both data and metadata? If yes, you could just as well have been running raid 0 and having more space and performance out of the same disks. Because of well documented issues, metadata on raid6 is not yet safe in power/hw failure situations. And if you have no safety in those situations, what is raid even for?

(It's perfectly safe to run metadata on raid1 and data on raid5/6.)

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#32

I'm curious how the benchmarks are for Btrfs on 6.1, given the improvements that (I think) landed in it: https://www.phoronix.com/news/Linux-6.1-Btrfs

This is exactly the sort of thing that Phoronix (will probably) benchmark

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#33

But is the RAID handling remotely sane yet? See https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... It has gems such as: * It won't boot on a degraded array by default, requiring manual action to mount it * It won't complain if one of the disks is stale * It won't resilver automatically if a disk is re-added to the array I think the first is the killer. RAID is a High Availability measure. Your system is…

No, they have plans for a new different RAID implementation as part of the "extent tree v2" thing AFAIK

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#34
post #5

I wonder how this compares to just using mdadm block device level raid5 or raid6. And then a normal filesystem on top.

The flexibility of software RAID is nice that you can mix and match hard drive manufacturers and generally have zero issues. For hardware RAID, I've always been told to stick to one drive family from one manufacturer and not to mix and match.

Generally every recommendation I've heard is don't use hardware RAID.

Some of the problems:

* RAID cards usually have under powered CPUs, and can easily be a bottleneck. Often the best performance with a RAID card is with the RAID disabled.

* Even battery backed RAM is often pretty slow and on the wrong end of a high latency connection between CPU/RAM and disks. Generally investments in ram or intentlog/writelog/slog is a better investment.

* Metadata is often undocumented, often needs backed up via obscure device dependent methods, and is required for a RAID adapter failure

* The firmware is often buggy, especially in the handling of the numerous failure modes.

* Recovery often requires the same card with the same firmware and a copy of the backed up metadata. Not all cards can recover all metadata from just the drives.

* Often are "too" smart, and won't export raw drives for use with more advanced filesystems like btrfs or ZFS. Some require ugly work arounds like exporting each disks as a single disk RAID0.

* Often RAID cards hide the SMART info from the OS, often crippling the ability to predict drive failures. Or hides the functionality behind a weird software stack that assumes a SMTP server and integrated poorly into whatever monitoring/alerting system you use for the operating system.

* Some RAID cards require a network connection and run a buggy and insecure out of data web stack on some undocumented and rarely (if ever) patched CPU that was obsolete the day it shipped.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#35
I've never lost data with btrfs, but I have purposefully avoided anything other than basic disk configurations. I use it on my workstations because it's the default in Fedora these days and haven't had any complaints.

On the flip-side, I've done some of the most horrible things possible and screwed up my 30-disk ZFS array a number of times and I've never lost data. I doubt btrfs could recover from anything I've done to break my ZFS pool.

Overall I think it's a huge shame that it was determined that the CDDL was incompatible with the GPL, because it wasn't intentional, and we would be in a completely different spot for storage otherwise.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#36

But is the RAID handling remotely sane yet? See https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... It has gems such as: * It won't boot on a degraded array by default, requiring manual action to mount it * It won't complain if one of the disks is stale * It won't resilver automatically if a disk is re-added to the array I think the first is the killer. RAID is a High Availability measure. Your system is…

> It won't boot on a degraded array by default, requiring manual action to mount it

If you want it to behave like that then add 'degraded' to fstab. That a device is missing can have unknown reasons, the user should know better and resolve it or allow such boot. It's not automatic as there's no way to inform the user that it's degraded state.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#37

Maybe I'm just cynical but I think the ship has sailed for BTRFS RAID 5/6. It's now part of the global mindshare that BTRFS RAID 5/6 == data loss, no one wants to be the guinea pig that proves it works. Better to direct resources towards bcachefs or ZFS IMO.

ZFS will never be mainlined so it’s beyond useless.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#38

Maybe I'm just cynical but I think the ship has sailed for BTRFS RAID 5/6. It's now part of the global mindshare that BTRFS RAID 5/6 == data loss, no one wants to be the guinea pig that proves it works. Better to direct resources towards bcachefs or ZFS IMO.

ZFS will never be mainlined so it’s beyond useless.

ZFS is widely used by many users and organizations. Just because it is not currently included in the Linux kernel does not mean that it is useless. There is ongoing work to integrate ZFS into the Linux kernel, and in the meantime, many users continue to find value in using ZFS on their systems. As an alternative, you could try using FreeBSD, which includes ZFS as part of the kernel. This can make it easier to take advantage of the features and benefits of ZFS without having to install and configure it separately. Additionally, because ZFS is integrated into the kernel, it can take advantage of FreeBSD's advanced security and performance features.

Re: Btrfs in Linux 6.2 brings performance improvements, better RAID 5/6 reliability

#39

I've never lost data with btrfs, but I have purposefully avoided anything other than basic disk configurations. I use it on my workstations because it's the default in Fedora these days and haven't had any complaints. On the flip-side, I've done some of the most horrible things possible and screwed up my 30-disk ZFS array a number of times and I've never lost data. I doubt btrfs could recover from anything I've done…

Never lost any data either in 10y of use as main driver.

I've ditched RAID 5 mostly because performance sucked so much, but I have never lost any data despite going through many changes of hard drives, changes of RAID mode, rebalancing, etc.

The closest I've come to losing data is probably rotten HDD sectors, but it's always been caught and remapped by scrubs.

Yes, there is the infamous write hole, but that's not a BTRFS only problem.

Post reply on HN