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

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

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.

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?

I also have no idea how grody it's going to be to retarget fusex and how
much QA is going to break because now all the iomap stuff branches off
from an *unstable* base.

The other wart of course is how mad will John be when I tell him that
fuse+iomap+dax+raid is now a looong way away...

--D