[dijit]

> 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?

[wtallis]

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.

[dijit]

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.

https://lwn.net/Articles/100330/