On Wed, Jul 22, 2026 at 5:47 AM Amir Goldstein <[email protected]> wrote:
>
> On Wed, Jul 22, 2026 at 12:47 PM Miklos Szeredi <[email protected]> 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.
>
> My bad. I thought that FUSE_DEV_IOC_STRIPE_OPEN was an
> example of how GET_FMAP should be made into a generic interface.
I had the same impression as Amir. The FUSE_DEV_IOC_STRIPE_OPEN patch
[1] right now is only for the interleaved case to handle striping, but
imo it seems a lot cleaner to make FUSE_DEV_IOC_STRIPE_OPEN a generic
interface for handling any backing layout that corresponds to a
backing id, and having the simple extent case go through this same
infrastructure / path. Especially since John's future patches for
adding the interleaving will go through the ioctl, it seems nicer
server-side as well for famfs to have one consolidated path instead of
needing two totally different ones. I think also file passthrough will
want this infrastructure in the future too, and their use case would
be mostly non-striped extents.
I was imagining something like:
struct fuse_backing_member {
uint32_t backing_id;
uint32_t reserved;
uint64_t offset;
uint64_t length;
};
struct fuse_backing_layout {
uint16_t nr_members;
uint16_t reserved1;
uint32_t reserved2;
uint64_t chunk_size;
uint64_t flags;
struct fuse_backing_member members[] __counted_by(nr_members);
};
which is the same as what was in the FUSE_DEV_IOC_STRIPE_OPEN patch
but just renamed and a uint64_t flags and uint64_t length field added.
This would let us eliminate GET_FMAP, which imo needs to be
eliminated. The ioctl also gives famfs more flexibility with being
able to preload extent mappings outside of the hot path instead of
being forced to only upload it on opens.
If not the ioctl, what did you have in mind for a generic interface? I
think anything else would have to keep GET_FMAP, but maybe I'm wrong
here.
I think John has patiently endured a lot of demands in the last 2
years, so I agree that anything that isn't uapi-dependent should just
be done in the future as follow-up work and shouldn't block this
series. imo the ideal version of this series would have nothing famfs
specific in it, but I think a lot of that can be renamed /
restructured internally later on. But the extent uploading / GET_FMAP
part seems like the last thing needed to figure out.
Thanks,
Joanne
[1]
https://lore.kernel.org/linux-fsdevel/[email protected]/#t
