On Fri, Aug 28, 2026 at 12:39:56PM -0500, John Groves wrote:
On 26/08/24 09:41AM, Miklos Szeredi wrote:
quoted
On Sat, 22 Aug 2026 at 23:55, John Groves [off-list ref] wrote:
quoted
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?
quoted
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.
quoted
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.
quoted
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? ;).
Excellent news and thanks for your patience and working with Miklos on
this.