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 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.

> > * iomap filesystems (when they arrive) always set FUSE_I_EXCLUSIVE
> 
> Yes.

Ok, thanks for the quick responses! :)

--D

> Thanks,
> Miklos