Re: [post LSFMM summary] where is fuse going?

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

On Wed, May 20, 2026 at 09:24:05PM +0200, Amir Goldstein wrote:
> On Wed, May 20, 2026 at 12:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > On Tue, May 19, 2026 at 11:01:18AM +0200, Miklos Szeredi wrote:
> > > On Tue, 12 May 2026 at 22:23, Darrick J. Wong <djwong@kernel.org> wrote:
> > >
> > > > As for fuse-iomap I'm not sure how to proceed
> > >
> > > I will try to dedicate this week to reviewing fuse-iomap, hopefully
> > > without too many distractions.
> >
> > Well gosh I had better get going on posting v9 then.
> >
> > Since 30 April I've:
> >
> > * Ripped out the BPF stuff after all the shouting
> > * Added a simplistic iomap filesystem striping mechanism
> > * Tightened some of the checking of the iomaps being given to the kernel
> > * Made it so that you can remove backing devices
> > * Actually check read/write access with the iomap bdevs
> > * Improved inline data write handling to be less flakey
> > * Amended iomap writeback so that you can run a standard ->iomap_begin
> >   to collect mappings
> > * Banned freeze except on iomap filesystems
> >
> > * Fixed some integer truncation issues
> > * Add some iomap helpers to libfuse to make it easier for fuse server
> >   authors
> >
> > > >  -- in the long run I think
> > > > it would be cleaner if each file IO path (virtiofs dax, passthrough,
> > > > writeback_cache, iomap, and whatever we call the original one) had its
> > > > own file_operations.  But that would require us to refactor the common
> > > > code chunks from each file operation function into a bunch of smaller
> > > > functions, which I think would sharply increase the review backlog.
> > >
> > > And so the plan is rather to basically start from scratch and do that
> > > form the beginning in fusex code.
> >
> > Heh.  In reading through the fuse code to figure out how I'd get that
> > done, I came to a few realizations:
> >
> > 1. It really *is* easier if the server can set FUSE_CAP_IOMAP and from
> > then on every file on the filesystem does things the iomap way.
> >
> > 2. Many of the random weird callers of fuse_inode_has_iomap() outside of
> > the regular file IO path are *actually* looking for "is this an
> > exclusive-mode inode"?  That's pretty much all of the file attribute and
> > ACL handling code.
> >
> 
> When you use the term "exclusive mode" you mean the same thing as
> "local" filesystem as opposed to "remote" (or clustered) filesystem that
> can have attribute changes on the server and needs to implement revalidate.
> Is that right?

Right.  A local filesystem driver knows it has exclusive ownership over
the disk contents, and hence the filesystem.  It doesn't have to worry
about external changes to the filesystem metadata.

> Can we maybe stick to the "local"/"remote" terminology?
> Or am I missing something subtle?
> 
> > 3. iomap and exclusive mode are mostly orthogonal concepts.  One deals
> > with plumbing, the other deals with attributes.
> >
> >    3a: iomap without exclusive: This is a clustered filesystem client.
> >    The client grabs a file layout lease from the server, and uses that
> >    to populate the iomappings.  Timestamp updates are forced out after
> >    each write, but otherwise it's the same attr cache and timeout that
> >    regular fuse uses
> >
> >    3b: iomap with exclusive: This is basically fuse4fs and all the other
> >    local filesystems.  The kernel knows that the fuse server isn't going
> >    to change the file attrs out from underneath it, so it can cache
> >    timestamp updates in the kernel and only flush them periodically.
> >
> > 4. Figure out how all the attribute handling works in fuse is really
> > really complicated.
> >
> > But there are questions here -- I'd like it if the fuse server could set
> > FUSE_CAP_IOMAP and all files are iomap.  All the weird userspace inode
> > flags setup setup code goes away.  It'd be even nicer for 3b if you
> > could declare at mount time (or FUSE_IOMAP_CONFIG time) whether you want
> > exclusive mode or not, at which point all files *also* become exclusive
> > files.
> >
> > The problem with 3a is that I don't have a client or any way to test
> > that.  If I just don't allow iomap && !exclusive, how sad would anyone
> > be?
> >
> 
> My view is that as long as you keep the design sufficiently extensible
> to support iomap && !exclusive in the future,
> let those who care enough about iomap && !exclusive step forward
> to code and review and test it if they care enough.

Heh.  Disentangling all the existing file attr and caching code is going
to take me a long time...

--D