Comment by f_devd
3 days ago
FYI XFS is not redundant, also RAID usually refers to software RAID these days.
I like btrfs for this purpose since it's extremely easy to setup over cli, but any of the other options mentioned will work.
3 days ago
FYI XFS is not redundant, also RAID usually refers to software RAID these days.
I like btrfs for this purpose since it's extremely easy to setup over cli, but any of the other options mentioned will work.
btrfs RAID is quite infamous for eating your data. Has it been fixed recently?
To be fair, your statement could be edited as follows to increase its accuracy:
> btrfs is quite infamous for eating your data.
This is the reason for the slogan on the bcachefs website:
"The COW filesystem for Linux that won't eat your data".
https://bcachefs.org/
After over a decade of in-kernel development, Btrfs still can't either give an accurate answer to `df -h`, or repair a damaged volume.
Because it can't tell a program how much space is free, it's trivially easy to fill a volume. In my personal experience, writing to a full volume corrupts it irretrievably 100% of the time, and then it cannot be repaired.
IMHO this is entirely unacceptable in an allegedly enterprise-ready filesystem.
The fact that its RAID is even more unstable merely seals the deal.
> Btrfs still can't either give an accurate answer to `df -h`, or repair a damaged volume.
> In my personal experience, writing to a full volume corrupts it irretrievably 100% of the time, and then it cannot be repaired.
While I get the frustration, I think you could have probably resolved both of them by reading the manual. Btrfs separates metadata & regular data, meaning if you create a lot of small files your filesystem may be 'full' while still having data available; `btrfs f df -h <path>` would give you the break down. Since everything is journaled & CoW it will disallow most actions to prevent actual damage. If you run into this you can recover by adding an additional disk for metadata (can just be a loopback image), rebalancing, and then taking steps to resolve the root cause, finally removing the additional disk.
May seem daunting but it's actually only about 6 commands.
3 replies →
No. RAID 5/6 is still fundamentally broken and probably won't get fixed
This is incorrect, quoting Linux 6.7 release (Jan 2024):
"This release introduces the [Btrfs] RAID stripe tree, a new tree for logical file extent mapping where the physical mapping may not match on multiple devices. This is now used in zoned mode to implement RAID0/RAID1* profiles, but can be used in non-zoned mode as well. The support for RAID56 is in development and will eventually fix the problems with the current implementation."
I've not kept with more recent releases but there has been progress on the issue
I believe RAID5/6 is still experimental (although I believe the main issues were worked out in early 2024), I've seen reports of large arrays being stable since then. It's still recommended to run metadata in raid1/raid1c3.
RAID0/1/10 has been stable for a while.