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@xxxxxxxxxx> wrote:
> >
> > From: Darrick J. Wong <djwong@xxxxxxxxxx>
> >
> > 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.
>
