Basically everything related to multiple disks is super basic and too simple.
1. If you are writing with the `single` profile. It always writes to the one with the most space. This means that adding a new disk to a system will hotspot writes to that disk. Alternatively you can rebalance and it will make it so that all disks have the same space available which will basically hotspot reads. Most sane filesystems will do some sort of balancing.
2. If you are writing to the `RAID0` (striping with no redundancy) it will write across all disks and fill them up equally. When one disk fills it will be dropped out and the other disks will be hotspotted.
3. If you read from a replicated profile it picks the disk based on your process ID rather than any sort of intelligent metric like queue length or typical latency.
4. Replication profile can only be set on the filesystem level. bcachefs can set replication profile on the per-file or recursively at the directory level.
I mean nothing is absolutely terrible. But it is just shockingly basic for many things.
I don't care about the raid features personally, that's irrelevant to me. I care about snapshotting and send streams more than anything else.
Your anecdotal evidence about data loss is meaningless. I can counter with my own anecdote: I've had zero data loss with btrfs running pre-release RC kernels on my laptops for over a decade. I fill up disks a lot.
One failure report is worth 1,000 success reports. Add as many orders of magnitude as you wish, and the statement remains true. This is not merely an axiom of reviewing and assessment, it's a joke:
I've been reviewing tech for a living for nearly 30 years now, and evaluating tech for a living -- as well as using it and fixing it and deploying it -- since the decade before that.
The point of tech assessment and tech reviewing is to balance the good features against the bad features. Too many people get dazzled by the good stuff so that they don't notice the bad stuff.
As the late great Douglas Adams put it:
«
In other words - and this is the rock-solid principle on which the whole of the Corporation's Galaxywide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws.”
»
I don't care how good the features of a filesystem are if I can't trust it. Either it needs to be very solid, and have good documented battle-tested tools for fixing it and repairing it, such as XFS or JFS... which probably means it is also conservative on the features.
Or, alternatively, absolutely blasted bulletproof, to the extend that a multi-billion-dollar corporation sees fit to launch it without a repair tool because it doesn't need one.
There is one such system, and it is ZFS.
Btrfs is neither. It is loaded with features, some half implemented if that, it is fragile, and it does not have good repair features.
If I had seen it fail once, I would be dubious and sceptical.
If I had seen it fail twice, I would no longer trust it.
But I have not. I have seen it fail half a dozen times in 4 years.
And it is not just me.
Here is the documentation on the repair tool:
«
Warning
Do not use `--repair` unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. E.g. some other software or hardware bugs can fatally damage a volume.
»
This tool cannot be trusted and that it is present means that the FS cannot be relied upon.
This is a giant red flashing light and eardrum-bashing warning siren.
It doesn't matter how many people like it and have had no problems. THERE ARE PROBLEMS. It doesn't matter how many corporates use it. A broken tool may still be usable.
Meta may deploy Btrfs across racks of kit but they don't care about the data on those racks and it can be replaced.
Fedora doesn't use snapshot support because it's bodged that functionality into OStree so it doesn't care if it's dangerous. It just wants to describe how horrendously inefficient Flatpak is.
I've used btrfs for about two years and in that time it completely destroyed my filesystem and almost lost data. Not trusting it again.
Realistically, that's a basic requirement for any filesystem. I've not had a filesystem do that in my two plus decades of linux usage. That means I'm just not using it. Restored to ZFS from backup and couldn't be happier. ZFS works; is extraordinarily stable; and hasn't lost data for me yet.
1. If you are writing with the `single` profile. It always writes to the one with the most space. This means that adding a new disk to a system will hotspot writes to that disk. Alternatively you can rebalance and it will make it so that all disks have the same space available which will basically hotspot reads. Most sane filesystems will do some sort of balancing.
2. If you are writing to the `RAID0` (striping with no redundancy) it will write across all disks and fill them up equally. When one disk fills it will be dropped out and the other disks will be hotspotted.
3. If you read from a replicated profile it picks the disk based on your process ID rather than any sort of intelligent metric like queue length or typical latency.
4. Replication profile can only be set on the filesystem level. bcachefs can set replication profile on the per-file or recursively at the directory level.
I mean nothing is absolutely terrible. But it is just shockingly basic for many things.