Re: [PATCH V12 02/12] famfs: Module operations, fs_context, and mount

["John Groves" <john@groves.net>]

On Fri, Aug 21, 2026, at 2:39 PM, Miklos Szeredi wrote:
> On Fri, 21 Aug 2026 at 13:40, David Hildenbrand (Arm) <david@kernel.org> wrote:
> 
> > (a) Whether a fuse-based approach is feasible.
> >
> >     Are there any major blockers remaining?
> 
> No.

Famfs does work in fuse, but some of the asks are things that I don't see
how I can agree to. I think Miklos and I should discuss those 1:1, to figure
out if there is a way forward.

I think the virtual backing-dev thing is a non-starter, and I think that the famfs
portion of the fuse ABI basically can't live without extents that are
(daxdev, offset, length). 

And taking out the interleaved fmap structure, which I did in v11 because
it's my perception that certain fuse people *hated* it, is a bad idea IMO - it 
explodes famfs fmaps from a few hundred bytes to potentially many 
megabytes with no benefit to famfs. And famfs still needs compact 
interleaved maps in the metadata log, because that memory is expensive.

I have little doubt that 1) I don't fully understand Miklos' concerns and
priorities, and 2) Miklos and others don't fully understand mine. If you 
think I'm bad at explaining famfs now, you should have seen me trying 
3.5 years ago! ;)

IMO the on-list discussions have failed, and if people want famfs in fuse,
Miklos and I should try to work out a plan 1:1. I've thought this since the first 
time we discussed in f2f at LPC in Vienna, when you had questions about 
the interleaved layouts.

> 
> > (b) Whether a fuse-based approach is inefficient.
> >
> >     Are there scenarios remaining where performance or metadata overhead would
> >     be bad without an easy way to improve the situation?
> 
> Lookups can be cached, extent mappings can also be cached.   After the
> inode is in cache and the mapping is set up zero requests are needed
> for open/mmap/read/write/close.

True as far as it goes. The initial statement I made at LSFMM '24 was that
famfs would have to cache up complete file maps in-kernel, and that's what
I implemented.

> 
> > (c) Whether a fuse-based approach is a bad conceptual fit.
> >
> >     Will fuse have to carry a lot of famfs special sauce that cannot
> >     really be used elsewhere / generalized?
> 
> None.
> 
> But "can" and "will" are not the same.  The striping code might not be
> very useful outside of famfs.

Right. Famfs is a file system that uses dax instead of the page cache,
and that dax is character not block, and there is no backing store. Famfs
is not even storage, since the memory is volatile. So it's pretty different 
from mainline file system use cases.

In the thread from hell prior to LSFMM, somebody asked if I'm willing
to have the famfs code be shared. I don't even understand the question:
it's open source, of course it can be shared. Whether it will make much 
sense to do that is an open question IMO.

Also, I'm curious: if you don't know of a use case for the striping code outside
of famfs, why ask famfs to completely rewrite that?  (and I agree, other
than the eventual remote possibility of competing 'famfs-ng' fuse servers, 
I don't see much likelihood that this piece will be shared.)

> 
> > (d) Whether a fuse-based approach is too invasive.
> >
> >     Will fuse extensions to support famfs actually make it harder to maintain or
> >     slower on some paths?
> 
> No.

This does depend on what architectural changes are demanded of
famfs.

> 
> > (e) Whether a fuse-based approach will make famfs harder to extend.
> >
> >     Is there known follow-up work that will be hard/impossible to model in fuse?
> 
> It would actually make famfs much easier to extend, since the
> directory structure, metadata, etc. is now controllable within the
> userspace server.

That is also true of the standalone famfs implementation, although the
fuse approach is nicer for this.

> 
> > (f) Whether a fuse-based approach will reduce maintenance effor
> >
> >     Will maintaining fuse extensions possibly be harder than maintaining
> >     standalone famfs?
> 
> Testing is a key point.  Famfs needs special hardware or emulation, so
> it's not straightforward to test.  This could be solved by adding a
> "dummy" mode to famfs server that exercises the same fuse API, but
> instead of special hardware would just use plain memory.

Famfs has extensive CI that runs against both the standalone and fuse
implementations, including legacy versions that are still in use.

We copied some of the dax CI; some of the tests build a kernel, boot it
in qemu with NFIT virtual daxdevs, build the famfs user space in the VM, run
CI tests on famfs in the vm, etc.

We also run test automation on real shared memory hardware, but those
are still unicorn setups currently.

My team is quite serious about the testing (regardless of which version
goes upstream), and will be running automated testing against famfs 
on every kernel release, with multiple versions of the user space - and 
we'll be happy to share the recipes with others.

> 
> > (g) Whether a fuse-based approach would make famfs more complex.
> >
> >     Will the shift to user space result in a significantly more complicated
> >     overall solution that must be maintained?
> 
> The server would be somewhat more complex, since it's now implementing
> things like pathname lookup, etc.  But the other stuff (managing file
> maps) should be very similar.

The famfs fuse server exists, and it did add quite a bit of statefulness and
complexity to famfs relative to standalone. But that's sunk work, and it's 
pretty well tested. 

> 
> > (h) Who would help drive the fuse approach?
> >
> >     Fuse people seem to be willing to help, but I expect that there must be a
> >     close cooperation with John to make this fly. I don't expect that John
> >     himself can easily (or understandably wants to :) ) do the heavy fuse
> >     lifting.
> 
> Yes, this is where previous efforts seem to have gone off the rails.
> So I agree to take responsibility for implementing the kernel side and
> help with the server side on the condition that John has trust in
> this.   I'm not promising -7.4, but can at least try.
> 
> Without John's trust I'm not taking this on.

I think I already did the heavy fuse lifting. There are a handful of things
that need to be reconciled / negotiated.

Miklos, I trust that you are a good faith actor, although you seem to be
spread pretty thin. Can you commit to a series of 1:1 conversations with
me to try to work through the disconnects? 

> 
> > (i) Who would maintain any famfs fuse extensions and own any bugs?
> >
> >     famfs will possibly depend on fuse extensions that might initially only be
> >     used by famfs. Would the fuse maintainers just naturally deal with that?
> 
> I can take responsibility for the fuse kernel bits.

I can share responsibility for the famfs-specific stuff.

> 
> > (j) Whether a fuse-based approach has an end in sight.
> >
> >     famfs goes back .... quite a long time. It would be nice to close that
> >     chapter :)
> >
> >     Is there an end in sight, or could we end up in the same situation in 6m/1y/
> >     ...
> >
> >     IOW, is there a way to agree on an MVP that won't require a lot of further
> >     re-planning and changes to a fuse-based design?
> 
> I already sent patches to implement the dax dev mapping, and the
> striping.  We've discussed adding support for fixed backing ID, which
> was something that John asked for.  The only missing piece was adding
> a protocol extension to set up  simple extent mappings, which already
> existed in the famfs_fuse patch, just needed to be renamed and unused
> fields changed to "spare".

I think the virtual backing dev idea is wrong and bad. Let's discuss that.

> 
> We (Amir, Joanne, me) explained to John how this is exactly what's
> needed to make famfs work.  We've not seen an acceptance of that yet.

I am not feeling that my technical concerns have been heard and 
understood, and I have not thought that the suggested changes to famfs 
would preserve its fitness for purpose. 

Whether I'm right or wrong can be figured out if we discuss it 1:1. The 
on-list conversations have been something that my cardiologist asked
me to stop reading. (only semi-joking)

> 
> From my PoV this would be extra work, but in the longer term would
> expect to be less overall maintenance work and fuse would gain some
> useful features in the process.
> 
> Thanks,
> Miklos
> 

Wherever we are, we've gotten here without any 1:1 collaboration. Let's
try some.

Thank you,
John