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

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

On Mon, May 11, 2026 at 05:12:42PM +0200, Miklos Szeredi wrote:
> Please let know what I missed.
> 
> CO-MAINTAINER:  Position still open, though we formalized some
> subsystem maintainership roles, sent MAINTAINERS patch.
> 
> FAMFS: Let's try to find some common ground between the fuse-iomap api
> and the famfs api.  I.e. add striping as a generic mapping method,
> even though normal filesystems don't (currently) use it.  Using BPF is
> a bad idea.

Hrmm well that /will/ delay famfs even more.  I *do* have a patchset
that adds striping abilities, but it's tacked on the end of the existing
fuse-iomap patches.

> FUSE-IOMAP: Need to reduce the scope of the patchset further, as no
> one can sanely review it.  Idea: first just implement static maps
> (i.e. read-or-re-write-only).  This should be much simpler, yet could
> demonstrate a read-only mount of ext4, right?

I don't think doing static maps would help much with reviewability.

Most of the complexity with non-static maps (e.g. delayed allocation,
unwritten extent conversion, out of places writes) are already handled
in fs/iomap/ or by the fuse server itself.  The only part that needs
help from fuse is the FUSE_IOMAP_IOEND command so that iomap can tell
the fuse server whether or not the operation succeeded so the server can
decide what to do with the state that it speculatively created.

[If I misread the sentence and you're interested in starting with
readonly files first, then let me say that the bulk of the new code in
the direct/pagecache IO patches that isn't the IO path itself are the
file attribute updates that happen before or after a write.  So I
could yank the _read_iter code out of the direct/pagecache IO patches.
It's not an exciting patch since you end up with a pile of thin wrappers
around iomap_dio_rw, generic_file_read_iter, iomap_bio_readahead, and
iomap_bio_read_folio.

In other words, we'd go from two large patches to two large patches and
two small patches.]

What I could do is break up the branches into even smaller pieces, and
then we could try to merge the smaller pieces.  Keep in mind that all
the iomap functionality is gated off until the last patch of the iomap
cache patchset even if CONFIG_FUSE_IOMAP=y.  That enables us to merge
the iomap code without enlarging the userspace ABI until we're ready to
merge that final patch.

Then we can try to review 4-5 patches at a time, and merge as many
pieces that pass muster.  The other question is -- who is willing to
review with me (besides Codex)?

Until that time, to create a program that would be broken by an ABI
change, you'd have to build your own kernel with a patch applied and
enable an option in Kconfig, and convince people to run that kernel.  In
other words, you'd have to be a fuse developer. ;)

> COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
> 
> FILE HANDLES: same: let's add to fusex.
> 
> URING BUFFER MANAGEMENT: there's a disagreement between Joanne and
> Bernd about this.  I think we first need a very high level description
> of each solution and why it's preferred over the other.

(I'm so unfamiliar with this topic I didn't even realize there were
competing solutions.  But I'd need some Dumm Manager Cave Drawings to
understand it.)

> LARGE FOLIOS: depends on !strictlimit.  I don't have a good enough
> understanding of writeback throttling to decide whether removing the
> strictlimit requirement for unprivileged fuse is okay or not.  Need
> more analysis.
> 
> FUSEX: there was approval for the idea of using this as a uAPI major
> version update.  In other words fusex will gain feature parity with
> legacy fuse, but with a more consistent interface.

Hrm.  At first I formed the impression that fusex was supposed to be a
(subset?) of regular fuse to explore making something a little more
targeted towards to local filesystems.  But the discussions since then
indeed make it sound like this is more about declaring that more
features will always be on, and some old APIs are now gone.

As for fuse-iomap I'm not sure how to proceed -- 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.

--D

> MAILING LIST: we have a shiny new one, there was agreement that it's
> sufficient for normal fuse discussion and patch posting, and usually
> there's no need to cross post linux-fsdevel.
> 
> Amir asked about how long it took for overlayfs to go upstream.  Well,
> I looked up both fuse and overlayfs:
> 
> fuse first release: Nov 2001
> fuse merge: Sep 2005
> 
> ovl first patchset: Aug 2010
> ovl merge: Oct 2014
> 
> Both 4 years ±2 months.
> 
> So don't despair! There's light at the end of the tunnel (and
> hopefully not the oncoming train ;)
> 
> Thanks,
> Miklos
>