On 26/08/24 09:41AM, Miklos Szeredi wrote: > On Sat, 22 Aug 2026 at 23:55, John Groves <[email protected]> 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
