Re: [PATCH 4/8] fuse: signal that a fuse filesystem should exhibit local fs behaviors

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

On Wed, Sep 24, 2025 at 10:31:36AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 24, 2025 at 03:55:48PM +0200, Miklos Szeredi wrote:
> > On Tue, 23 Sept 2025 at 22:51, Darrick J. Wong <djwong@kernel.org> wrote:
> > 
> > > Oh, ok.  I can do that.  Just to be clear about what I need to do for
> > > v6:
> > >
> > > * fuse_conn::is_local goes away
> > > * FUSE_I_* gains a new FUSE_I_EXCLUSIVE flag
> > > * "local" operations check for FUSE_I_EXCLUSIVE instead of local_fs
> > > * fuseblk filesystems always set FUSE_I_EXCLUSIVE
> > 
> > Not sure if we want to touch fuseblk, as that carries a risk of regressions.
> 
> Hrm.  As it stands today, setting FUSE_I_EXCLUSIVE in fuseblk mode
> solves various mode/acl failures in fstests.
> 
> On the other hand, mounting with fuseblk requires fsname to point to a
> block device that the mount()ing process can open, and if you're working
> with a local filesystem on a block device, why wouldn't you use iomap
> mode?
> 
> Add to that Ted's reluctance to merge the fuseblk support patches into
> fuse2fs, and perhaps I should take that as a sign to abandon fuseblk
> work entirely.  It'd get rid of an entire test configuration, since I'd
> only have to check fuse4fs-iomap on a bdev; and classic fuse4fs on a
> regular file.  Even in that second case, fuse4fs could losetup to take
> advantage of iomap mode.
> 
> Yeah ok I've persuaded myself to drop the fuseblk stuff entirely.  If
> anyone /really/ wants me to keep it, holler in the next couple of hours.

Ted agrees with this, so I'm dropping fuseblk support for fuse[24]fs.

--D

> > > * iomap filesystems (when they arrive) always set FUSE_I_EXCLUSIVE
> > 
> > Yes.
> 
> Ok, thanks for the quick responses! :)
> 
> --D
> 
> > Thanks,
> > Miklos
>