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

On Fri, 2026-08-21 at 17:21 -0700, Darrick J. Wong wrote:
> On Fri, Aug 21, 2026 at 09:39:26PM +0200, Miklos Szeredi wrote:
> > On Fri, 21 Aug 2026 at 13:40, David Hildenbrand (Arm) <[email protected]> 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.
> 

Agreed -- this is exactly my take as well. While I sent a R-b for
John's standalone work, I've no issue if the better path forward is
deemed to be FUSE. I'd just like to see this come to some sort of
resolution.

Cheers,
-- 
Jeff Layton <[email protected]>