Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

phoronix.com

Post reply on HN
Print view View original

71–80 of 231 posts

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

#71

Post by pavon »

Gigachad wrote: post #43
DominoTree wrote: post #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…

I feel like the data loss risk doesn't really make sense to be worried about. It doesn't matter what FS or storage system you use, you _need_ a backup if you actually care about the data. And if you have backups, you are fine. As a random anecdote I've been using BTRFS for everything for over 7 years now and had no issues. Think the only FS I've ever had problems with was ExFAT.

I think it is important for two reasons. First, the primary purpose of RAID is to improve availability of your data, such that you can continue operating in spite of a hardware failure. If the RAID feature of btrfs has serious data loss problems, then it is taking a feature that is supposed to increase availability, and instead decreasing it. It is like an UPS that is more likely to cause a power outage than to protect you from one.

The other reason is that the atomic snapshot feature, and ability to easily transfer diffs of snapshots makes a wonderful foundation for incremental backups. But if I can't trust the filesystem to avoid corrupting my data, how can I trust it to avoid corrupting my snapshots? Hence I can't trust my backups. So I need to go back to a more independent backup processes like rsync.

With those two features gone, my whole motivation for using btrfs over simpler file systems like ext4 is gone, so why bother.

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

#72

Post by _kdave »

denkmoon wrote: post #21
candiddevmike wrote: post #8

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.

Do Meta not develop btrfs for their internal use? I don't think community sentiment is a big factor for them.

AFAIK they use it internally, there are articles on lwn.net how, the use cases is for root filesystems and containers. I'm not sure I understand what you mean by the community sentiment, there are examples of code they'd developed internally first and sent it upstream, but in all cases I remember there were no problems. What can happen in the community is e.g. how the patches are organized or if the changelogs are complete. It's of course easier to develop something internally, if it touches other subsystems or if there's enough coverage just for the new code the test/fix/deploy cycle is much flexible. Once it's supposed to go through mailinlists or convincing other maintainers to accept changes it takes longer and must stick to the development cycle. This benefits both sides in the long run.

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

#73

Post by josephcsible »

klysm wrote: post #24
dale_glass wrote: post #19

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 That by itself is a complete deal breaker.

IMO, the inconvenience this causes is outweighed by the prevention of data loss for people who otherwise would never have noticed the degraded array.

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

#74

Post by Gigachad »

pavon wrote: post #71
Gigachad wrote: post #43

Earlier quoted context omitted.

I feel like the data loss risk doesn't really make sense to be worried about. It doesn't matter what FS or storage system you use, you _need_ a backup if you actually care about the data. And if you have backups, you are fine. As a random anecdote I've been using BTRFS for everything for over 7 years now and had no issues. Think the only FS I've ever had problems with was ExFAT.

I think it is important for two reasons. First, the primary purpose of RAID is to improve availability of your data, such that you can continue operating in spite of a hardware failure. If the RAID feature of btrfs has serious data loss problems, then it is taking a feature that is supposed to increase availability, and instead decreasing it. It is like an UPS that is more likely to cause a power outage than to prote…

>With those two features gone

Still seen no real proof this is true. It's always vague feelings and anecdotes. has anyone done any real testing to measure file corruption?

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

#75

Post by jiggawatts »

dale_glass wrote: post #19

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…

The list of bugs and counter-intuitive design decisions in BTRFS RAID should make anyone pause before ever considering it as a viable filesystem for anything.

It's like people justifying MySQL saying that it's okay for it to lose or corrupt data, and that transactional integrity doesn't matter as much as people say it does.

Yeah, maybe if you're website is a blog. But anyone storing real data should run away screaming from systems like this.

Maybe MySQL is sort-of-okay now? I dunno. It's possible BTRFS RAID 5 won't eat your data or crash your server regularly now.

I'm going to stay away from both anyway.

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

#76

Post by viraptor »

Hello71 wrote: post #67
_kdave wrote: post #36

Earlier quoted context omitted.

> 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.

according to https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu... , btrfs devs say you should not add degraded to fstab, and doing so can easily result in data loss.

The quote is "At this stage of development, a disk failure should cause mount failure so you're alerted to the problem." and it's from over 9 years ago on an ancient kernel. That was just 3+ years since btrfs project got started.

Let's treat it as archived historical content it is.

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

#77

Post by Teknoman117 »

helf wrote: post #46

I ran into a major problem with performance on btrfs when used on an extremely high write volume that filled up. Between fragmentation and full disk I couldn’t even /copy/ data off the drive at a reasonable rate. It was a perfect storm of me being an idiot and heavy use. But I dunno if they have remotely resolved the issues

I actually hit this for the first time in all my years of using btrfs a few weeks ago.

Every month or so I spin up external drives to write out monthly backups of my NAS and personal computers. Forgot I'd taken on the home video collection and overfilled the array. Deleting some old subvolumes and having the space reclaimed took hours (on a 99.9% full 5 TB RAID-1 volume). Part of that is that I use compress=zstd:10 on the external drives, but I wasn't expecting it. Writes speeds tanked to tens of KB/s. Since these are those Seagate drives from Costco, probably also SMR drives...

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

#78

Post by simcop2387 »

dekhn wrote: post #27
dale_glass wrote: post #19

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…

Many folks I know who manage storage don't make the boot volume RAID (redundant)- instead, it's some rapidly duplicatable thing like an NMVE flash containing the root filesystem, and there's a replacement handy. Then you can bring up and bring the full power of userspace to bear on the RAID repair.

The way I like to do it is with mirroring of the nvme storage and then lvm snapshots on top of it. Done correctly you get boot off either of them but they're kept in sync automagically by the OS. then you snapshot the boot volume regularly and copy those to some kind of archival storage for backups.

That lets you then even hotswap them if you need to while keeping the root filesystem workable.

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

#79

Post by helf »

Teknoman117 wrote: post #77
helf wrote: post #46

I ran into a major problem with performance on btrfs when used on an extremely high write volume that filled up. Between fragmentation and full disk I couldn’t even /copy/ data off the drive at a reasonable rate. It was a perfect storm of me being an idiot and heavy use. But I dunno if they have remotely resolved the issues

I actually hit this for the first time in all my years of using btrfs a few weeks ago. Every month or so I spin up external drives to write out monthly backups of my NAS and personal computers. Forgot I'd taken on the home video collection and overfilled the array. Deleting some old subvolumes and having the space reclaimed took hours (on a 99.9% full 5 TB RAID-1 volume). Part of that is that I use compress=zstd:10 o…

Yes! I actually gave up on the one drive. It was a torrent disk (like I said worst case scenario for a lot of things) and btrfs ate itself lol.

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

#80

Post by freeqaz »

We run BTRFS on our work laptops and have been for a few years now. Keep in mind that we're only 4 devs, so our sample size is small, but we haven't had any issues with it so far and it's been very pleasant to use so far!

We published our internal doc for how we install our Arch setup with fully encrypted BTRFS if anybody is curious. Happy to answer any questions too!

https://www.lunasec.io/docs/blog/arch-linux-installation-gui...

(We run Thinkpad X1 Extremes (+ the business P1 equivalents) as our dev boxes.)

Post reply on HN