Re: [PATCH V12 02/12] famfs: Module operations, fs_context, and mount
"John Groves" <[email protected]>
| Newsgroups | org.kernel.vger.linux-doc,dev.linux.lists.fuse-devel,dev.linux.lists.nvdimm,org.kernel.vger.linux-cxl,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Aug 24, 2026, at 2:41 AM, 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 > I'll ping you directly about times to talk. Thank you for being willing to do that. Regards, John