Re: Steam?
> simple mdadm, LVM, or btrfs setup
No. So very much no.
1. "Simple" does not go with "LVM" and I'd challenge its use with Btrfs.
2. Btrfs is as unreliable as hell. Btrfs is the reason Bcachefs says it won't eat your data. Btrfs makes the `df` command tell lies, and it doesn't have an `fsck`, and the repair command destroys filesystems. This is easily confirmed: both the Btrfs official docs and SUSE docs tell you _not_ to run it.
2. You use "or". In other words, you seem to be saying use _either_ mdadm, _or_ lvm, _or_ Btrfs. This means you've missed the point of ZFS, which is that it does the primary functionality of all of those, and it does it in one tool.
None of those work alone. mdadm makes block devices but then you need a filesystem on top.
LVM manages partitions dynamically -- good -- in a horribly complicated way -- bad -- and then you need a filesystem on top.
Btrfs can do some of what both of them do, so it overlaps, because it can't do all of it, so you need to use multiple tools anyway, and the result is more complex than any of them alone. This is bad.
ZFS does all of that, in one place in one tool.
It makes arrays, it manages pools, you can add and remove disks, enlarge arrays, and it also manages formatting them and mounting/unmounting them, and dynamically moving volumes around within them.
It's also very very solid, unlike Btrfs. Fill a Btrfs volume and kiss your data good bye: it's dead, gone, irretrievable.
I've not lost a byte on ZFS yet, in coming up on 5 years. Btrfs died on me at least twice a year and I never _ever_ successfully retrieved anything.
As if this combination of provincialism, ignorance, and disinformation wasn't bad enough, then in another comment you double down on it:
> if things go South with your storage server you can boot any Linux live CD/USB then (if needed) modprobe btrfs to have access to your data.
Yeah, no. Because that applies to ZFS as well, and I've done it. I bunged Xubuntu on a key and manually did a file-level dedupe when I accidentally filled an array.
And the good thing is, with a full array, it coped fine and didn't drop a single packet.
No. I call BS.
Look, you may be familiar and comfortable and happy with Btrfs and mdadm and LVM and maybe all of them. Good for you. I am not saying you are wrong or they don't work. They do. There are big caveats but they are in use by millions of machines.
But you are using your apparent ignorance of why ZFS exists to decry it, when the responsible adult thing to do is go "hey, people say this is good, I should try it". Because that is what I did. I tried all of them. mdadm is great. I've been using it for decades. It's fine.
LVM is a PITA and the kernel team should have picked EVMS instead.
Btrfs is dangerously fragile and I will never trust it again. It is I am sure perfectly possible to plan for its fragility and work around it but you should not have to.
But they OVERLAP and that is BAD.
Using 2 of them means intersection of functionality. Let's say LVM offers even-numbered tools and Btrfs odd-numbered ones. You need an array across lots of disks. Alice will build a server use tools 1, 3, and 5, while Bob uses 1, 2, and 4. Charlie uses 2, 3, 4 and 5.
Trying to work out which and why and where is dangerous territory.
But worse is using all three, when you don't know if the RAID is by mdadm but the encryption is LVM and the snapshots are Btrfs, or was it LVM snapshots on a Btrfs RAID...
No.
The point is, overlapping tools are hazardous. Which is _why_ ZFS was built. It does the logical volume management, and the array management, and the encryption, and the mountpoint management, and the monitoring, and it does it all in one place.
The result may be less flexible but the win from having it all in one place is _significant_.
Before you pontificate on it, you need to research this stuff and know, and it looks to me like you didn't.
The result is like a Vim user taking the mickey out of Eclipse without ever taking the time to look and realise that while Vim is faster and they know it well, Eclipse also does a dozen other things that the Vim user had to use other tools _as well_ to achieve.
Biting the hand that feeds IT
