Not a file system developer but an ardent ZFS user. Here are my thoughts.
I pick ZFS every time because of its usability, reliability, and being able to easily understand what goes on without being a master of the OS ecosystem it runs on.
For example, pick ZFS, and sit with the ZFS handbook for 15 minutes and you already know how and what to do to:
[Create/modify/destroy] X [Vdev/Zpools/datasets]
A disk gives out, it is easy to k ow what to do to let ZFS deal with it without googling hard and relying on forums about what the right thing to do for your OS is - unless you already know it.
ZFS is not the fastest filesystem to pick with it being a COW fs. But, it does everything so well, feels solidly thought out that it gives a lot of confidence to the user which is very important aspect for a file system.
I hope bcachefs and many other modern filesystems that are vying for mainstream adoption like ZFS keeps these virtues from ZFS. Until then, I would happily try and play with them, but not think about using them in stuff I really care about.
Panics and other issues are pretty rare for regular users that don't push ZFS to its limits with over-utilized RAM or obscure kernel and/or ZFS features, but when you do encounter problems, you better know some kernel internals kung-fu if you want to keep using recent kernel and ZFS versions rather sooner.
(This argument is mainly about ZoL though; I can't speak for Illumos or FreeBSD that have somewhat tighter integration between ZFS and the rest of the kernel.)
Hmmm. True that when you encounter a panic or a serious error, and you lack serious system/kernel/OS skills, it can be real trouble. But still less so than picking a new/developing filesytstem. There are so many eyes on ZFS that one would hope someone with the skills you lack is already looking at that serious issue or at least will do if you file a bug report.
As a personal experience, I have two ZFS based file servers being hammered by researchers pushing it in many weird IO patterns, bursts requests and so for about a year and half without ever hitting a serious error. I'm amazed by how rock solid the system is. One of them even has a Optane cache for NFS writes- just to give you an idea of feature richness.
FreeBSD+ZFS on a dedicated server+JBODs. I keep the infrastructure dead simple and they are a charm.
That is only because the author (kent overstreet) based it on his former work bcache.
Fyi he now has fully persistent allocation info done so his attempt ti mainline it should start soon. Even though I still got open bug reports left I'm excited about this.
He checks his code against the xfs test suite so hopefully it really will be stable and useable.
My main problems with bcachefs are:
* it's mainly one developer
* when I tested it I had problems many times
* he documents his progress irregular(ly) (not frequently with pauses and at different places: bcachefs.org, patreon home, patreon posts)
* he doesn't answer questions (on his patreon posts or on github bug reports) (this could be a good thing if he only wants to concentrate on code)
* while waiting om bcachefs becoming mature, butterfs became finally mature (kind of)
So even thought I'm following the project I'm not sure if compression now has working disk space accounting or not and similar things, but since I see admirable progress I'm still looking forward for the first mainline release
I think there have been updates after every bigger piece of work recently. They were irregular because the work took different amount of time. He never promised scheduled updates as far as I remember.
I'm really only talking about documenting not patreon posts. For instance the patreon main page says compression is working with lz4 and zlib, the bcachefs homepage says lz4, zlib and zstd (with zstd having problems).
Also the mount times mentioned on the homepage are afaik (could be wrong) not that big of a ptoblem anymore and only slow because of the optional fsck
I do feel less confident trusting by data to one person hacking on one file system compared to a tried and tested file system that was built by Sun’s best engineers. CoW support in Linux is good but lack of snapshots still makes this an inferior choice to zfs.
I wish the GPL zealots wouldn’t bark that loud every time someone mentions ZFS on Linux. Ubuntu is shipping next release with ZFS on root. It will be awesome.
I thought the Ubuntu's decision that they can include it in their release was controversial but are they that convinced the license allows them to do that?
Well, it did originate from the realization that a good block caching layer designed for SSDs was most of the way to being a real filesystem in its own right. The caching is the biggest advantage bcachefs has over other filesystems, and the name does end in "FS". Perhaps it's a personal bias that makes you inclined to think dismissively of something as "just" a caching layer, when it's actually a really hard problem?
Perhaps it's a personal bias that makes you inclined to think dismissively of something as "just" a caching layer, when it's actually a really hard problem?
I was providing a possible answer to the question: why do people not give bcachefs more attention as a filesystem?
> Perhaps it's a personal bias that makes you inclined to think dismissively of something as "just" a caching layer, when it's actually a really hard problem?
That’s quite incendiary.
I also assumed it was a caching filesystem based on the name. Something you could attach to LVM or BTRFS to cache disk write or read on access.
Because despite the fact there is “fs” there is “cache” written there. And caching filesystems would indicate that instead of just using ram it would use some kind of traditional storage. It’s not unthinkable that this is a common thought process. What kind of “personal bias” could exist which alters what a caching filesystem would mean?
I didn't mean to be incendiary, just to point out that different experiences could be leading people to make inaccurate assumptions.
And I'm a bit confused by what you mean when you say "caching filesystem", since you seem to be using that term to talk about something that isn't a filesystem at all, rather than a filesystem that has advanced caching capabilities on its feature list. (cf. terms like "checksumming filesystem", "copy on write filesystem", "journalling filesystem") I was careful to refer to the original bcache and similar tools as "caching layers" rather than mislabel them as filesystems, but bcachefs is a proper filesystem.
A caching filesystem (as opposed to a standard block storage filesystem) would be one used for cached data specifically. ZFS has cache drives but the actual on disk layout does not resemble ZFS as we know it. That’s what I’m eluding to;
ZFS in this case is an all-in-one solution so it’s perfectly fine to refer to it as a feature of the filesystem, but externalising that to a separate agnostic product would result in this being exposed.
In fact CacheFS was designed exactly like this, and as you can see includes both “cache” and “FS” in the name.
I pick ZFS every time because of its usability, reliability, and being able to easily understand what goes on without being a master of the OS ecosystem it runs on.
For example, pick ZFS, and sit with the ZFS handbook for 15 minutes and you already know how and what to do to:
[Create/modify/destroy] X [Vdev/Zpools/datasets]
A disk gives out, it is easy to k ow what to do to let ZFS deal with it without googling hard and relying on forums about what the right thing to do for your OS is - unless you already know it.
ZFS is not the fastest filesystem to pick with it being a COW fs. But, it does everything so well, feels solidly thought out that it gives a lot of confidence to the user which is very important aspect for a file system.
I hope bcachefs and many other modern filesystems that are vying for mainstream adoption like ZFS keeps these virtues from ZFS. Until then, I would happily try and play with them, but not think about using them in stuff I really care about.