Re: [PATCH 06/23] fuse: add an ioctl to add new iomap devices

["Darrick J. Wong" <djwong@kernel.org>]

On Thu, Aug 21, 2025 at 10:09:29AM +0200, Amir Goldstein wrote:
> On Thu, Aug 21, 2025 at 2:54 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > From: Darrick J. Wong <djwong@kernel.org>
> >
> > Add an ioctl that allows fuse servers to register block devices for use
> > with iomap.  This is (for now) separate from the backing file open/close
> > ioctl (despite using the same struct) to keep the codepaths separate.
> 
> Is it though? I'm pretty sure this commit does not add a new ioctl
> and reuses the same one (which is fine by me).

Oops, stale message. :(

<snip>

> > diff --git a/fs/fuse/backing.c b/fs/fuse/backing.c
> > index c128bed95a76b8..c63990254649ca 100644
> > --- a/fs/fuse/backing.c
> > +++ b/fs/fuse/backing.c
> > @@ -187,10 +193,13 @@ int fuse_backing_close(struct fuse_conn *fc, int backing_id)
> >          * error code will be passed up.  EBUSY is the default.
> >          */
> >         passthrough_err = fuse_passthrough_backing_close(fc, fb);
> > +       iomap_err = fuse_iomap_backing_close(fc, fb);
> >
> >         if (refcount_read(&fb->count) > 1) {
> >                 if (passthrough_err)
> >                         err = passthrough_err;
> > +               if (!err && iomap_err)
> > +                       err = iomap_err;
> >                 if (!err)
> >                         err = -EBUSY;
> >                 goto out_fb;
> 
> Do you really think that we need to support both file passthrough and file iomap
> on the same fuse filesystem?

Probably not.

> Unless you have a specific use case in mind, it looks like over design to me
> We could enforce either fc->passthrough or fc->iomap on init.
> 
> Put it in other words: unless you intend to test a combination of file
> passthrough
> and file iomap, I think you should leave this configuration out of the config
> possibilities.

Nah, one subsystem per backing device_id is ok with me.  If someday
someone builds a hybrid filesystem then ... hopefully they don't need
more than INT_MAX backing files to be in the index.

--D

> Thanks,
> Amir.
>