11–20 of 112 posts
Earlier quoted context omitted.
What about ZFS?
Suspect as well --- for the same reason. System level data handling functionality is critical and needs to be rock solid. Complexity makes this more difficult to achieve. Not to say it's impossible, just increasingly more difficult.
And in practice ZFS is extraordinarily solid.
Btrfs is usable in mirror mode.
Raid is still unusable (as in: you will lose data)
Usage and tooling are unintuitive and dangerous.
I have to say, it doesn't sound so bad when you know what you're doing. The example from the article - the fact that you need to re-silver and re-balance a mirror after a failure - yes that is dangerous. But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed.
And let's remember that some mdadm raids don't auto-scrub periodically. So the essence is: Storage is still hard, it's still necessary to think before you manage disks.
Btrfs is flexible and works well for self-hosted home storage use cases, especially running cheap hardware & HDDs with mixed RPM + capacity specs (many consider it a major advantage over OpenZFS on Linux which inherits ZFS pros and cons). As far as data corruption is concerned, avoid using raid{5,6} profile (that governs how a chunk is replicated within or across a member device) for data and you should be fine. Runn…
From my experience, Ubuntu's ZFS support is pretty solid, even for root disks. There were some limitations in the past, however - for example, you might not want to use ZFS on a ssd root because of its write amplification.
By the way, there's a handy PPA with newer versions [2] - but this does use DKMS.
Do one thing and do it well. Do too much and you may end up like Btrfs.
What about ZFS?
Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at the level of small/personal devices anywhere anymore, and really it never will be.
And as you scale higher, single filesystems just don't cut it anyway. Cloud storage paradigms work on much larger bits, and worry about things like multi-site failover and atomicity. ZFS/btrfs has nothing to offer someone working on an S3-like service, or a globalized database, either.
I mean, it's fine. Use it if you like it and you have an esoteric application that can leverage it (lots of hackers' personal networks tend to have toys like that). For that matter btrfs is fine too; my main data server at home is scripted around btrfs snapshots because they're easy.
But really... fancy filesystems are just software in need of a home. Run ext4 or whatever and don't sweat it.
[1] Non-encryption checksumming anyway. dm-verity doesn't work at the filesystem layer, nor should it.
Earlier quoted context omitted.
Suspect as well --- for the same reason. System level data handling functionality is critical and needs to be rock solid. Complexity makes this more difficult to achieve. Not to say it's impossible, just increasingly more difficult.
I disagree. I think that the traditional split between block devices and file systems is a premature optimization that ZFS fixes. And in practice ZFS is extraordinarily solid.
As long as you never ever run into an edge case it's great, but then again the same goes for btrfs :)
One 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.
Earlier quoted context omitted.
What about ZFS?
ZFS is a more mature and (maybe?) more performant solution to... the same wrong problem. The modern world doesn't want this stuff from its filesystems. It just doesn't. Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at th…
I'm regularly working with datasets in the single to two digit TB range. They need to sit on disk because the university doesn't have 10GE.
If I ran a regular raid and would encounter a disk or data error, I would have to re-create the data from tape archive or worse, lose it; and getting a replacement disk would surely take weeks.
So instead, I've been running raidz pools for ~10 years and have never skipped a beat.
I agree that this is not very typical, but it suits my needs perfectly.
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.
They merged the Btrfs and ZFS teams, they then worked on ZFS entirely with no Btrfs work, and then basically reassigned, fired, or otherwise dissolved the ZFS team when it became clear that OpenZFS (Sun's chosen steward for ZFS) could not be swayed.
Btrfs has had no real work done on it since then, and anyone that is actually serious about data storage has moved to ZFS, or has left POSIX filesystems entirely.
One 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.