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

[Darrick J. Wong]

On Fri, Aug 21, 2026 at 09:39:26PM +0200, Miklos Szeredi wrote:
> On Fri, 21 Aug 2026 at 13:40, David Hildenbrand (Arm) <david@xxxxxxxxxx> wrote:
> 
> > (a) Whether a fuse-based approach is feasible.
> >
> >     Are there any major blockers remaining?
> 
> No.
> 
> > (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.
> 
> > (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.
> 
> > (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.
> 
> > (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.
> 
> > (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.
> 
> > (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.
> 
> > (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.

Whatever path you and John decide on, I would very much like to see the
question of Which famfs driver do we merge? to be resolved for 7.4.

--D

> > (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.
> 
> > (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".
> 
> 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.
> 
> 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