On Fri, 19 Apr 2019 09:20:41 +0200 Daniel Cegiełka <daniel.cegie...@gmail.com> wrote: > * ZFS > Resource-consuming. Designed for large servers. > > * btrfs > Rather a good choice for server rooms (Facebook). > > * bcachefs > A good competition for btrfs/ZFS.
One thing that ZFS offers that most other filesystems don't is very strong
data consistency guarantees. This is important especially if you plan to
store data for any length of time. Turns out storing data for years or even
decades is actually quite hard, due to generic bit rot (hardware failure,
cosmic rays, etc.) even when using mirrored RAID.
In fact, in many filesystems there are very weak – or no! – guarantees that
the data you're reading is actually correct. Systems like ext4 simply assume
that the data written to the disk will never change. AFAIK, it has
essentially no mechanism at all to deal with silent data corruption.
Unfortunately, there are also many downsides to ZFS; the license, much bloat
("kitchen sink and then some"), performance on "old" hardware, etc.
At a glance, btrf also seems to have *some* data consistency guarantees,
although I'm not sure if they're as good as ZFS. Besides, btrfs doesn't seem
stable as a general purpose filesystem[1], and I'm not sure if it'll ever
be.
I had never heard of bcachefs before, but it seems interesting. Checksums
are done per file (extent)[2] rather than per block (which is what ZFS
does), which will make data recovery harder after corruption. Still, it's
better than ext4 or JFS (which has no checksums at all). According to the
Patreon homepage it seems to be in the early stages of being stable.
Personally I would consider data integrity guarantees to be the most
important feature of a filesystem, and will gladly lose performance or
features for it. After all, what good is high performance or fancy features
if your data is corrupt?
Back to JFS: it offers no strong data consistency guarantees, and would
consider it to be the same class of legacy file system that ext4, xfs, ufs,
etc. belong to. Also, according to Wikipedia there is a problem with its
Journal design that may cause loss of data:
> [Journal writes] can be postponed until there is another trigger —
> potentially indefinitely, which can cause data loss over a theoretically
> infinite timeframe.
Yikes(?)
Conclusion: bcachefs is probably the future(?)
[1]: https://github.com/mosteo/btrfs-status
[2]: https://www.patreon.com/posts/bcachefs-extents-20740671
pgpMeBe08q0OP.pgp
Description: OpenPGP digital signature
