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.
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.
Bcachefs got
He checks his code against the xfs test suite so hopefully it really will be stable and useable.My main problems with bcachefs are:
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