Well, at least there's a chance. Now, ReiserFS 4...
His sentence will be served as of sometime in 2023.
Examining Btrfs
71–80 of 112 posts
Re: Examining Btrfs
#72Yet another knock-off of Lustre. Lustre is not perfect, and I'm not suggesting it has a place in the mainline kernel, but it sounds like neither does BTRFS.
When you get to large scale (multi-petabyte) filesystems there are not many options, it's GPFS, Lustre, or roll your own. Lustre development has been indirectly sponsored by the DoE for a long time now. And if Lustre didn't exist IBM would charge even more for GPFS. But at least Lustre is free. But it's not a walk in the park to use.
Re: Examining Btrfs
#73One thing I always found curious is that Synology supports Btrfs. Granted, they are not exactly what I'd call a company with a rock-solid track record, but they are still a rather large premium manufacturer in the NAS space. It seems they have either managed to contain Btrfs' complexity and prevent users from doing the dangerous things, or their own hybrid raid was even worse, or they are just very risk friendly.
The most annoying issue I have with my Synology is that when I accidentally pulled out the power cord, it seems to have forgotten its configuration. Only Synology support knows the commands required to get it all up and running, they sorted it remotely, BUT, I rebooted it and it promptly forgot its settings. They sorted it AGAIN, but said only way to sort it is to reformat and rebuild.
If it can be restored to normal functionality with a few commands, surely they should be able to save the configuration for subsequent reboots?
No data was lost, btw.
Re: Examining Btrfs
#74>Moving beyond the question of individual disk reliability, btrfs-raid1 can only tolerate a single disk failure, no matter how large the total array is. The remaining copies of the blocks that were on a lost disk are distributed throughout the entire array—so losing any second disk loses you the array along with it. (This is in contrast to RAID10 arrays, which can survive any number of disk failures as long as no two…
> This feels a little disingenuous to me. This is a distinctly RAID-1 problem. This doesn't feel like a BTRFS problem. Everyone knows RAID-1 = 1 drive loss. The point he's making is that classic RAID-1 is pairs of disks, of which you can lose one of the two, whereas btrs-raid1's (admittedly very neat) feature to bolt multiple disks together means you can end up with a situation where you can only lose one of N drives…
In BTRFS, RAID1 simply means 2 copies on different devices. There is RAID1C3 and RAID1C4 if you want more redundancy/copies.
This whole critique boils down to poorly chosen naming and bad documentation. Both VERY valid critique. But feature-wise, BTRFS delivers „classic“ RAID1 and more/better. It’s just hard to find and easy to misread.
Re: Examining Btrfs
#75The ONLY time I've actually lost data, was with BTRFS, and only using it as a basic single-volume filesystem, no RAID, snapshots, or anything complex. BTRFS does not seem to recover well from media errors. I've had plenty of those, and always been able to recover at least partial data (minus the bad media) with other FS's.
I've had funny experiences with disappearing files on ext4 - reading a file while there are transient SATA errors (on a flaky SATA link) would cause a the file to be removed.
To be fair, I think I've lost more data on btrfs.
Re: Examining Btrfs
#76Earlier quoted context omitted.
> This feels a little disingenuous to me. This is a distinctly RAID-1 problem. This doesn't feel like a BTRFS problem. Everyone knows RAID-1 = 1 drive loss. The point he's making is that classic RAID-1 is pairs of disks, of which you can lose one of the two, whereas btrs-raid1's (admittedly very neat) feature to bolt multiple disks together means you can end up with a situation where you can only lose one of N drives…
In BTRFS, RAID1 simply means 2 copies on different devices. There is RAID1C3 and RAID1C4 if you want more redundancy/copies. This whole critique boils down to poorly chosen naming and bad documentation. Both VERY valid critique. But feature-wise, BTRFS delivers „classic“ RAID1 and more/better. It’s just hard to find and easy to misread.
I would argue btrfs does not deliver "classic" RAID1. Last I checked if you lose 1 disk in a 2 disk btrfs RAID1 setup and then reboot, it will be unable to mount the filesystem until you change the mount options so that it is set to 'degraded' mode. This is very different from other RAID1 setups (e.g. hardware raid controllers, mdadm, openzfs), and a big problem if you don't have lights out management or fast physical access to the machine.
Re: Examining Btrfs
#77Earlier quoted context omitted.
In BTRFS, RAID1 simply means 2 copies on different devices. There is RAID1C3 and RAID1C4 if you want more redundancy/copies. This whole critique boils down to poorly chosen naming and bad documentation. Both VERY valid critique. But feature-wise, BTRFS delivers „classic“ RAID1 and more/better. It’s just hard to find and easy to misread.
I would argue btrfs does not deliver "classic" RAID1. Last I checked if you lose 1 disk in a 2 disk btrfs RAID1 setup and then reboot, it will be unable to mount the filesystem until you change the mount options so that it is set to 'degraded' mode. This is very different from other RAID1 setups (e.g. hardware raid controllers, mdadm, openzfs), and a big problem if you don't have lights out management or fast physica…
I would argue that the 'degraded' stuff is a valid but different critique - and in fact is covered in a completely separate part of the article at some length.
Re: Examining Btrfs
#78How to kill your array - reboot your computer at a bad time. Who'd have thought raid1 could be so unreliable.
https://btrfs.wiki.kernel.org/index.php/Gotchas#raid1_volume...
I did end up having to copy the array out because of this. Copied it into a zfs array and am glad to be out of the land of gotchas.
Re: Examining Btrfs
#79Earlier quoted context omitted.
> This feels a little disingenuous to me. This is a distinctly RAID-1 problem. This doesn't feel like a BTRFS problem. Everyone knows RAID-1 = 1 drive loss. The point he's making is that classic RAID-1 is pairs of disks, of which you can lose one of the two, whereas btrs-raid1's (admittedly very neat) feature to bolt multiple disks together means you can end up with a situation where you can only lose one of N drives…
In BTRFS, RAID1 simply means 2 copies on different devices. There is RAID1C3 and RAID1C4 if you want more redundancy/copies. This whole critique boils down to poorly chosen naming and bad documentation. Both VERY valid critique. But feature-wise, BTRFS delivers „classic“ RAID1 and more/better. It’s just hard to find and easy to misread.
The critique is more about the fact that it'll stripe across any two devices in the pool.
So in an 8+4+2+2 setup, you could run into serious trouble after only losing the two 2Tb drives (which are likely the oldest and flakiest two in a bodged-together-from-leftovers style array).
I do agree that this is still strictly better than not being able to do it at all so long as you understand the risks, but being able to do RAID1 over 8+(4+2+2) would be even nicer for a bunch of uses and I've yet to figure out how to do that.
Re: Examining Btrfs
#80Earlier quoted context omitted.
I would argue btrfs does not deliver "classic" RAID1. Last I checked if you lose 1 disk in a 2 disk btrfs RAID1 setup and then reboot, it will be unable to mount the filesystem until you change the mount options so that it is set to 'degraded' mode. This is very different from other RAID1 setups (e.g. hardware raid controllers, mdadm, openzfs), and a big problem if you don't have lights out management or fast physica…
I would argue that the 'degraded' stuff is a valid but different critique - and in fact is covered in a completely separate part of the article at some length.
I think we are in agreement. I was responding to the comment that stated "BTRFS delivers „classic“ RAID1 and more/better.", which is what I am disagreeing with. Requiring that mount options be changed whenever there is a drive failure (despite having sufficient redundancy) is definitely an anti-feature in my book.