Re: [PATCH V11 0/9] famfs: port into fuse

On 26/07/22 12:46PM, Miklos Szeredi wrote:
> On Mon, 20 Jul 2026 at 12:07, Amir Goldstein <[email protected]> wrote:
> 
> > It's not about this ioctl, it's about infrastructure reuse.
> > It's about the fact that there is NOTHING special about dax_devlist;
> > and no reason not to manage it via backing_files_map.
> >
> > The reason you stated was that you want userspace to determine the
> > daxdev_index/backing_id - fine, no problem - this is why I asked that
> > you pass it the desired backing_id in the ioctl.
> > In fact I think that all fuse backing_ids would be better assigned by user space
> > so the extension of padding => backing_id is not unique to famfs.
> 
> Right, so I suggest to just reuse FUSE_DEV_IOC_BACKING_OPEN and add
> two flags: one to enable user supplied backing ID and the other to
> indicate that fd refers to DAX device.  The changes to do compared to
> the current patchset are quite minimal.
> 
> > And the best part is that this request requires no changes to your userspace.
> > You already bite the bullet and maintain the new/old uapi but changing the
> > kernel implementation does not require this burden from you, so to be honest
> > I really don't understand why you did not follow Miklos' suggestion.
> 
> Code reuse is also important, but I understand John's position to want
> to separate famfs from existing codebase as much as possible.  And
> because this is an implementation detail I don't want to make this a
> show stopper.  We can easily fix it later.
> 
> > > - Lose the famfs interleaved extent format. I have complied with this request.
> > >   It makes some things worse, but we'll discuss that later.
> > >
> >
> > I am really not aware of a request to lose the interleaved extent format.
> > How can this patch [2] from Miklos which reimplements this format as a generic
> > uapi be mistaken for a request to lose this format?
> 
> Let's not care.  We can easily add this later if famfs (or any other
> use case) decides to want this after all.
> 
> Making the initial patchset smaller is win in any case.
> 
> > Let me recap the former review requests as I understand them:
> >
> > 1. Use ioctl instead of GET_DAXDEV
> 
> This is done, just need to reuse the existing ioctl instead of add a
> new one with the same semantics (okay not true because of the fixed
> backing ID extension...)
> 
> > 2. Use backing files infra for daxdev table
> 
> Leave this later.
> 
> > 3. Use ioctl instead of GET_FMAP
> 
> Not sure we agreed to use an ioctl for extent mapping.   What we did
> agree on was to use a generic interface that doesn't have anything
> famfs specific in it.
> 
> John, can you please also look at review comments provided by Sashiko?
> 
> Thanks,
> Miklos

This a quick acknowledgment that I appreciate your reply Miklos. I'll respond
to individual points as soon as I can without rushing.

Re: Sashiko - of course! The series has been through /kreview in Chris'
review-prompts repo. Weird that I didn't get any email directly from Sashiko 
this time, but I know how to get to it online.

I will make this high-level comment: After reading Amir's initial reply, I 
concluded that the requested changes push famfs past the breaking point, 
and therefore the only way to keep famfs suitable for its intended usage is 
to pivot back to standalone. I do think that may be best all-around for fuse, 
famfs and Linux. I don't see any way famfs makes fuse better - it's a very 
specialized pattern that doesn't fit in a passthrough-filesystem or 
block-filesystem shaped hole. And I don't think it can comply with the 
"nothing famfs-specific in GET_FMAP" objective.

If famfs is standalone, it can only ever affect customers who use it, and it
cannot be used as a general purpose file system. When famfs is in fuse, it's 
mashed up with code for hundreds or thousands of other use cases. That's not 
a win from a risk management standpoint, and it doesn't make famfs better - 
certainly not in any way that would mitigate adding a lot of state / 
complexity / baggage to famfs.

In good faith,
John