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

41–50 of 231 posts

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

#41

Post by WastingMyTime89 »

herpderperator wrote: post #12

I've been managing a raid6 ext4 array with mdadm for 10 years. Started with 4 x 4TB disks and kept adding, up to 11 disks now. It works reliably and as designed. Had a few disk failures and replaced them without issues. That's one of the nice things about mdadm vs ZFS: you can add and remove disks from the array as you see fit, rather than being forced to upgrade all disks if you want to increase the size of your arr…

Why is this comment downvoted? ZFS limited disk management forcing you to use the size of the smaller disk and making it difficult to resize array is not a feature. It’s a serious limitation when using it as a normal user and not in a professional environment. It’s extremely annoying that most of the ZFS zealots are in denial.

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

#42

Post by helf »

WastingMyTime89 wrote: post #37
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.

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

Not mainlined = useless?

Ok.

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

#43

Post by Gigachad »

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.

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

#45

Post by dale_glass »

_kdave wrote: post #36
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 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.

I don't quite understand the use case here. If I'm setting up RAID it's because I want the system to stay up. That's the only purpose for it.

If a device goes missing for "unknown reasons", then the machine should still work, and I'll figure out what happened when monitoring pokes me and says RAID is degraded.

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

#46

Post by helf »

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

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

#47

Post by chomp »

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.

Why? Are you in a position where you can’t modify grub or fstab?

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

#48

Post by imiric »

oarsinsync wrote: post #29
herpderperator wrote: post #12

I've been managing a raid6 ext4 array with mdadm for 10 years. Started with 4 x 4TB disks and kept adding, up to 11 disks now. It works reliably and as designed. Had a few disk failures and replaced them without issues. That's one of the nice things about mdadm vs ZFS: you can add and remove disks from the array as you see fit, rather than being forced to upgrade all disks if you want to increase the size of your arr…

I did that for a long time. I reached 15 disks. Then something went wrong, and I lost everything. I now run multiple 6 disk raidz2s, in part because I wanted to remove the option that led me down the bad path. I hope your journey ends better than mine did.

Reading these horror stories just makes me not want to rely on smart filesystems at all. If a bug can take out my whole array, or if the system is as inflexible and magical as ZFS, I'd rather not rely on it at all.

I've been managing a home NAS for years with SnapRAID and plain old ext4. Sure, it doesn't have the bells and whistles of something like ZFS, but it's simple to use and understand, scales with anything you throw at it, and there's no way to lose the whole array.

I'm currently transitioning to a multi-node setup, and will probably move to Ceph, otherwise I would stick with SnapRAID. Every so often I look into btrfs/ZFS/mdadm, but keep reaching the same conclusion that it's just not worth the risk.

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

#49

Post by chasil »

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…

Regarding resilvering, I am amazed by ZFS' capability of quickly bringing a stale mirror back into synchronization.

I have used the FUSE port of ZFS to write only one member of a mirroset, then upon mounting both members elsewhere, the stale mirror was very quickly resilvered, so ZFS was able to determine only the blocks needing to be refreshed.

In btrfs, I understand that this requires a rebalance, which will read/write every used portion of the filesystem.

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

#50

Post by iwillbenice »

WastingMyTime89 wrote: post #37
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.

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

No post body was provided.
Post reply on HN