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

101–110 of 231 posts

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

#101

Post by ClumsyPilot »

josephcsible wrote: post #73
klysm wrote: post #24

Earlier quoted context omitted.

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

I think this is the difference in target audience - for home use, maybe I won't have monitoring, so it should fail to boot.

For enterprise, if you dont have monitoring setup it's on you

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

#102

Post by i13e »

I use BTRFS on my laptop and in case anyone is interested in trying it, please be sure you know how to chroot into the system in case it won't start. Arch Linux had a problematic GRUB package pushed to stable a few months ago and it bricked people's computers by booting directly to the BIOS. Whatever you do, make sure to take notes on the configuration (if it is DIY) because there are many difference between BTRFS and EXT4, so you can't use a normal chroot guide to fix your system.

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

#103

Post by _kdave »

dale_glass wrote: post #45
_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.

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.

Yeah but monitoring is not something that comes with the filesystem. If you have to set up the system to be a HA and configure monitoring, email notifications whatever, making sure the filesystem is created with redundant profiles, then I'm expecting that also adding the 'degraded' to the fstab is part of the configuration.

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

#104

Post by zeotroph »

simcop2387 wrote: post #82
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…

Only time I've lost data with zfs was when i was first doing something supremely stupid, mostly as a dare to see if it would work. I had recently upgraded my pool and had a bunch of old disks lying around so i fired them up in a new pool, 6x 4TB and 6x 8TB disks. I took the 4TB disks and set them in in a raid0 to get effectively 9x 8TB disks. Apparently doing this will work but you MUST make sure you properly wipe al…

Is there a zfs native way to create raid0 disks now? On Linux I usually set up a linear mapping with dmsetup, and then point zfs to that. But this hides the native disks from zfs.

I've done that a couple times to make a bunch of mismatched disk fit into zfs's requirement that all are of the same size. The ability to work with a mix of disk sizes is one advantage of btrfs - if you remember to be extra careful on a disk failure and bad shutdown. Plus the ability to dynamically grow the array, but there is work to improve that in the zfs side as well.

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

#105

Post by sedatk »

coptun wrote: post #60
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.

I've been rocking raid 5/6 btrfs for years for my personal data, no problems apart from the speed. A scrub literally takes months.

Yeah same here. Directory deletions are excruciatingly slow too.

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

#107

Post by p1necone »

dale_glass wrote: post #45
_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.

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.

> That's the only purpose for it.

That's not the only purpose for it. There's three reasons I can think of that you might set up a RAID array:

    * You want better uptime. (your use case)

    * You want to protect from data loss. (my assumption was that this is the most common use case, but I could be wrong. This also helps with uptime because there's nothing worse for uptime than having to restore lost data from a cold backup)

    * You want better performance, data integrity be damned. (RAID 0)
Booting a RAID array with a failed disk is a bad idea if you care a lot about not losing data, because now you're one less disk failure away.

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

#108

Post by zeotroph »

coptun wrote: post #60
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.

I've been rocking raid 5/6 btrfs for years for my personal data, no problems apart from the speed. A scrub literally takes months.

Months? I thought it would just go through all the data and verify that the stored checksums match. Even if it fetches filedata more than once to ensure the parity bits are ok, how can it take longer than reading the entire disk a couple times?

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

#109

Post by Teknoman117 »

helf wrote: post #79
Teknoman117 wrote: post #77

Earlier quoted context omitted.

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.

To be fair, it didn't break or lose data. Just got really, really slow until I let it finish reclaiming space.

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

#110

Post by dekhn »

alerighi wrote: post #91
dekhn wrote: post #27

Earlier quoted context omitted.

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.

I don't get why you need to do so. RAID is not a substitute of backups, and shouldn't used that way. Meaning that of course you have a backup of the data that you can recover from. RAID is used for two things: 1. improving the performance of slow disks (at least the read performance) 2. having 1/2 disk fail with your system remaining completely usable, till you replace the faulty disk as soon as possible. The second…

Regardless of what you think, many people keep a separate boot and data disk and don't use RAID on the boot disk. I never said anything about it being used for backups nor did I said anything about service outages. I think my point- about what other people do since I don't use RAID- is more about the choices different people make in terms of trusting their boot volume's recoverability in times of crisis.
Post reply on HN