On Thu, Aug 6, 2026 at 7:34 AM Darrick J. Wong <[email protected]> wrote:
>
> On Thu, Aug 06, 2026 at 06:19:49AM +0100, Matthew Wilcox wrote:
> > On Mon, Aug 03, 2026 at 10:52:19AM +0200, Amir Goldstein wrote:
> > > > The most important thing to know about famfs is that it CANNOT be used
> > > > as a
> > > > general purpose file system. It is for enabling file-based byte-level
> > > > access
> > > > (including direct mmap) to very large (e.g. 100TB) shared/disaggregated
> > > > memory appliances - which have become available during this long
> > > > process,
> > > > and which are in need of Linux support.
> > > >
> > > > So famfs cannot be used by anybody who doesn't know why they need it;
> > > > Making
> > > > famfs standalone means it can't affect users who don't use it. And my
> > > > super-
> > > > mega-corp employer (Micron), as well as other memory companies, need it.
> > > > We do not intend to abandon it, but imagine if we did: fs/famfs/ should
> > > > be
> > > > removed if the memory companies can't be bothered to maintain it.
> > >
> > > It does not work this way.
> > > When vfs maintainers accept standalone famfs they accept the burden of
> > > maintaining it whenever vfs internal APIs change even if the filesystem
> > > was
> > > abandoned by the mega-corps.
> > > That is the code of the push back for adding new filesystems.
> > > Removing the fs and breaking deployed systems is not an option for the vfs
> > > maintainers.
> >
> > Sure it is. We removed EFS just last month, because we decided that it
> > wasn't worth keeping any more. Just like we removed Itanium architecture
> > support (and a number of other architectures before that). We've removed
> > other filesystems in the past (xiafs, ext, surely a few others).
>
> and freevxfs just this week because the one user/complainer said hch
> could let it die.
>
Guys really, these examples prove what point exactly?
They prove that if all the users are gone we can remove a filesystem
wow, revelation.
This is the reality as I see it:
Famfs is backed by a major corp selling expensive hardware
and championed by John who has proved commitment above and beyond.
So as it stands, famfs is a fair candidate for merging standalone.
And yet, circumstances can and do change over the years.
I need only name your employer as a recent example of
major corp losing interest and axing the maintainers budget to many projects.
These things can and do happen and when they happen there is often
little correlation to the number of deployed users who paid many $$$ for the
expensive hardware, which major corp lost interest in maintaining.
If as a community we do not prepare ourselves for this possibility we
would be fools.
In the unlikely event of future famfs abandonment we are left with two technical
options depending on the choices that we make in the present:
1. The VFS maintainers are left to maintain an abandoned fs whose surface
area interacting with the code is super/inode/file/vm operations and more
2. FUSE maintainer is left to maintain an abandoned feature whose surface
area interacting with the code is substantially smaller - basically, some
custom logic for DAX fault handling - because the rest is (or can be)
plain fuse with a dash of fuse passthrough.
No option is categorically better or worse than the other.
The burden just falls on different people and the weight of the burden
depends on how much active development of the API is going on.
We have had many mostly-dead filesystems which did not bother anyone
for a long time, until someone comes along and starts a revolution in the API,
such as folios, iomap, new mount api, parallel dirops and then we pay the price,
or the abandoned customers pay the price.
I said enough, probably too much.
I'll be happy with any decision, just as long as we make it continuously
based on correct information.
Thanks,
Amir.
