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

[John Groves <john@groves.net>]

On 26/08/24 09:41AM, Miklos Szeredi wrote:
> On Sat, 22 Aug 2026 at 23:55, John Groves <john@groves.net> wrote:
> 
> > 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,
> 
> The virtual backing-dev is an abstraction.
> 
> Is it sufficient for you if I promise that this is going to do the
> same thing as the standalone famfs at the same performance level?
> 
> >  and I think that the famfs
> > portion of the fuse ABI basically can't live without extents that are
> > (daxdev, offset, length).
> 
> Sigh.  My proposal was (backing-id, offset, length).  Again this is an
> abstraction.  A backing ID can be a daxdev, a striped logical device
> or it can be a block dev or even a plain file.
> 
> > 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.)
> 
> Because the striping feature fits much better into a virtual device
> API than the extent mapping API.  This is how striping has worked in
> linux for the last 30 years.
> 
> > 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?
> 
> Fine, let's find a time.
> 
> Thanks,
> Miklos

Miklos and I met yesterday and I think we found workable path forward.
We will be collaborating on some changes to the famfs metadata transport,
likely mostly via me trying to make it easy for Miklos to bring up a
famfs testbed VM, and Miklos doing some re-work on famfs to make it
more consonant with fuse (fuse-onic? ;).

Meanwhile, the most recent standalone famfs series (v13) had some very 
helpful review comments - many of which apply to both the fuse and
standalone implementations. I plan to publish a v14 standalone branch
with those improvements, and also cross-port the appropriate portions
to the fuse series, which will probably be called v15.

That updated fuse series should be the foundation for Miklos' rework - 
and I'll get it ready as fast as I can.

Miklos, thank you for working with me on this. I think this was one of
those cases where there is no good substitute for face-to-face
collaboration.

Regards,
John