[post LSFMM summary] where is fuse going?

[post LSFMM summary] where is fuse going?

[Miklos Szeredi]

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.

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?

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.

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.

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

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

[Luis Henriques]

Hi Miklos,

On Mon, May 11 2026, Miklos Szeredi wrote:

> Please let know what I missed.

Thanks for the summary.  It looks pretty comprehensive to me, the only
things I don't see listed are the FUSE discord and the monthly/biweekly
call.  But that's probably out of the scope of this email.

Also...

[snip]

> COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
>
> FILE HANDLES: same: let's add to fusex.

I'd like to clarify this: do you see fusex as some sort of staging area
for features development that would (or could) eventually be merged back
into the "traditional" FUSE?

I'm asking because I got under the impression that file handles in
particular was something that would be desired to have in "traditional"
FUSE (and that's where I would rather have them TBH).  This would, for
example, help unbreak nfs exports.

Cheers,
-- 
Luís


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

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

[Horst Birthelmer]

On Mon, May 11, 2026 at 05:43:46PM +0100, Luis Henriques wrote:
> Hi Miklos,
> 
> On Mon, May 11 2026, Miklos Szeredi wrote:
> 
> > Please let know what I missed.
> 
> Thanks for the summary.  It looks pretty comprehensive to me, the only
> things I don't see listed are the FUSE discord and the monthly/biweekly
> call.  But that's probably out of the scope of this email.
> 
> Also...
> 
> [snip]
> 
> > COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
> >
> > FILE HANDLES: same: let's add to fusex.
> 
> I'd like to clarify this: do you see fusex as some sort of staging area
> for features development that would (or could) eventually be merged back
> into the "traditional" FUSE?
> 
> I'm asking because I got under the impression that file handles in
> particular was something that would be desired to have in "traditional"
> FUSE (and that's where I would rather have them TBH).  This would, for
> example, help unbreak nfs exports.
> 

I'm not that convinced that this is as easily doable as it looks at first glance.
Imagine you have a feature done in fusex.
The interface to vfs is the same and the interface to user space is the same
(to some degree, since there are those new opcodes)
but the inner workings are completely different.

I think the porting to traditinal fuse will pretty much be a rewrite, unless the
task was trivial in the first place.

Just my $.02

Horst

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

[Luis Henriques]

On Mon, May 11 2026, Horst Birthelmer wrote:

> On Mon, May 11, 2026 at 05:43:46PM +0100, Luis Henriques wrote:
>> Hi Miklos,
>> 
>> On Mon, May 11 2026, Miklos Szeredi wrote:
>> 
>> > Please let know what I missed.
>> 
>> Thanks for the summary.  It looks pretty comprehensive to me, the only
>> things I don't see listed are the FUSE discord and the monthly/biweekly
>> call.  But that's probably out of the scope of this email.
>> 
>> Also...
>> 
>> [snip]
>> 
>> > COMPOUND REQS: let's add this to fusex.  uAPI is simple, kAPI needs refining.
>> >
>> > FILE HANDLES: same: let's add to fusex.
>> 
>> I'd like to clarify this: do you see fusex as some sort of staging area
>> for features development that would (or could) eventually be merged back
>> into the "traditional" FUSE?
>> 
>> I'm asking because I got under the impression that file handles in
>> particular was something that would be desired to have in "traditional"
>> FUSE (and that's where I would rather have them TBH).  This would, for
>> example, help unbreak nfs exports.
>> 
>
> I'm not that convinced that this is as easily doable as it looks at first glance.
> Imagine you have a feature done in fusex.
> The interface to vfs is the same and the interface to user space is the same
> (to some degree, since there are those new opcodes)
> but the inner workings are completely different.
>
> I think the porting to traditinal fuse will pretty much be a rewrite, unless the
> task was trivial in the first place.

Right, I got the same feeling looking into the code.  But since the patch
description explicitly mentions this possibility of merging features into
the old code base, I figured I'd ask just to be sure.

Miklos, do you have a timeline for when fusex will be merged into
mainline?

Cheers,
-- 
Luís

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

[Miklos Szeredi]

On Tue, 12 May 2026 at 10:46, Luis Henriques <luis@igalia.com> wrote:

> Miklos, do you have a timeline for when fusex will be merged into
> mainline?

Haven't thought about it.  Could be merged as experimental with no
guarantees of api stability for some time yet.

Thanks,
Miklos

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

[Miklos Szeredi]

On Mon, 11 May 2026 at 18:43, Luis Henriques <luis@igalia.com> wrote:

> I'd like to clarify this: do you see fusex as some sort of staging area
> for features development that would (or could) eventually be merged back
> into the "traditional" FUSE?

Could do that, yes.

> I'm asking because I got under the impression that file handles in
> particular was something that would be desired to have in "traditional"
> FUSE (and that's where I would rather have them TBH).  This would, for
> example, help unbreak nfs exports.

I'm fine with that.  Especially since code can easily be shared between the two.

Thanks,
Miklos

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

[Amir Goldstein]

On Mon, May 11, 2026 at 5:12 PM Miklos Szeredi <miklos@szeredi.hu> 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.

IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
The simple nature of the maps, the fact that famfs maps are const and
queried at file open time makes me think that famfs is much closer to
PASSTHROUGH than it is to IOMAP (in its full capacity).

I think Joanne has mentioned that her customers have a use case for
multi backing ids per passthrough file and I assume this would be a pretty
simple map, so that sounds pretty darn close to famfs already.

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

One more perspective regarding FUSE-IOMAP which you mentioned in LSFMM:

wc -l fs/fuse/* on current master: 20875
wc -l fs/fuse/* on fuse-iomap-fileio: 25325

We have just taken a tiny bit of load off you by sub-maintaining
2200 LOC which you are less familiar with:

$ wc -l fs/fuse/backing.c fs/fuse/dev_uring.c fs/fuse/dev_uring_i.h
fs/fuse/iomode.c fs/fuse/passthrough.c
  179 fs/fuse/backing.c
 1371 fs/fuse/dev_uring.c
  211 fs/fuse/dev_uring_i.h
  275 fs/fuse/iomode.c
  197 fs/fuse/passthrough.c
 2233 total

Merging large new features without a sub-maintainer
is likely going to hurt your ability to keep your head above water.

I realize that it may be hard for people to commit and that the atmosphere
in workplaces is of great uncertainty, but this is something for you
to consider.

If we are being honest, then we need to develop features that users need
and if users need features, there are usually employers willing to pay for the
feature development and maintenance, if we let employers know that this is
what it takes to get their users what they need.

Thanks,
Amir.

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

[Gao Xiang]

On 2026/5/12 01:18, Amir Goldstein wrote:
> On Mon, May 11, 2026 at 5:12 PM Miklos Szeredi <miklos@szeredi.hu> 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.
> 
> IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
> The simple nature of the maps, the fact that famfs maps are const and
> queried at file open time makes me think that famfs is much closer to
> PASSTHROUGH than it is to IOMAP (in its full capacity).
> 
> I think Joanne has mentioned that her customers have a use case for
> multi backing ids per passthrough file and I assume this would be a pretty
> simple map, so that sounds pretty darn close to famfs already.

I vaguely remembered that Joanne mentioned that mapping multiple
backing files into one FUSE inode at the end of session.

Is that the case you mentioned here? The requirement _might_ be
reasonable, but how does the entire page cache work for such cases?
Each vma can only point to exact one single real vm_file and rmap
totally relies on it.

Unless there are some more non-trivial core-MM enhancement (e.g. to
split into several vmas for each range), I don't think it's possible
for the current page cache infra. For DAX, it might be possible
since DAX has a seperate workflow.

Thanks,
Gao Xiang

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

[Amir Goldstein]

On Tue, May 12, 2026 at 5:20 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2026/5/12 01:18, Amir Goldstein wrote:
> > On Mon, May 11, 2026 at 5:12 PM Miklos Szeredi <miklos@szeredi.hu> 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.
> >
> > IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
> > The simple nature of the maps, the fact that famfs maps are const and
> > queried at file open time makes me think that famfs is much closer to
> > PASSTHROUGH than it is to IOMAP (in its full capacity).
> >
> > I think Joanne has mentioned that her customers have a use case for
> > multi backing ids per passthrough file and I assume this would be a pretty
> > simple map, so that sounds pretty darn close to famfs already.
>
> I vaguely remembered that Joanne mentioned that mapping multiple
> backing files into one FUSE inode at the end of session.
>
> Is that the case you mentioned here? The requirement _might_ be
> reasonable, but how does the entire page cache work for such cases?
> Each vma can only point to exact one single real vm_file and rmap
> totally relies on it.

The problem is only with  fuse_passthrough_mmap().
Depending on the workload (?) mmap may not be important and
we could fail if trying to map cross-backing-id regions.

For the rest of the I/O passthrough method we could usually do
a short read/write (?).

The main question to ask IMO is "is this useful" and the use case
and workload and customer will determine the answer to this question.

>
> Unless there are some more non-trivial core-MM enhancement (e.g. to
> split into several vmas for each range), I don't think it's possible
> for the current page cache infra. For DAX, it might be possible
> since DAX has a seperate workflow.
>

But we can also say that mapping multiple backing id should be
implemented with IOMAP, but this is also closer to famfs, because
this use case is the const static mapping determined at open time.
In a way, this is exactly the minimal subset of FUSE-IOMAP that
could be implemented and share most of the code needed by famfs.

Joanne, is there an actual workload like this or was your comment
a "maybe in the future" sort of comment?

Thanks,
Amir.

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

[Miklos Szeredi]

On Tue, 12 May 2026 at 09:53, Amir Goldstein <amir73il@gmail.com> wrote:

> The problem is only with  fuse_passthrough_mmap().
> Depending on the workload (?) mmap may not be important and
> we could fail if trying to map cross-backing-id regions.

mmap(2) is the main entry point into famfs,  so it's very important.

That doesn't work with "traditional" passthrough and needs to do the
DAX mapping that famfs currently does.

Thanks,
Miklos

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

[Amir Goldstein]

On Tue, May 12, 2026 at 12:01 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Tue, 12 May 2026 at 09:53, Amir Goldstein <amir73il@gmail.com> wrote:
>
> > The problem is only with  fuse_passthrough_mmap().
> > Depending on the workload (?) mmap may not be important and
> > we could fail if trying to map cross-backing-id regions.
>
> mmap(2) is the main entry point into famfs,  so it's very important.
>
> That doesn't work with "traditional" passthrough and needs to do the
> DAX mapping that famfs currently does.
>

Yes, famfs surely needs mmap to multiple daxdev and this is done.

I was referring to Gao's question about dealing with non-dax multi
backing id (const mapped) files.

Thanks,
Amir.

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

[Gao Xiang]

On 2026/5/13 05:40, Amir Goldstein wrote:
> On Tue, May 12, 2026 at 12:01 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>>
>> On Tue, 12 May 2026 at 09:53, Amir Goldstein <amir73il@gmail.com> wrote:
>>
>>> The problem is only with  fuse_passthrough_mmap().
>>> Depending on the workload (?) mmap may not be important and
>>> we could fail if trying to map cross-backing-id regions.
>>
>> mmap(2) is the main entry point into famfs,  so it's very important.
>>
>> That doesn't work with "traditional" passthrough and needs to do the
>> DAX mapping that famfs currently does.
>>
> 
> Yes, famfs surely needs mmap to multiple daxdev and this is done.
> 
> I was referring to Gao's question about dealing with non-dax multi
> backing id (const mapped) files.

Yes, it can work on DAX and my question was all about
mmap backed by multiple pagecache-backed files.

Thanks,
Gao Xiang

> 
> Thanks,
> Amir.

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

[Miklos Szeredi]

On Mon, 11 May 2026 at 19:18, Amir Goldstein <amir73il@gmail.com> wrote:

> IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
> The simple nature of the maps, the fact that famfs maps are const and
> queried at file open time makes me think that famfs is much closer to
> PASSTHROUGH than it is to IOMAP (in its full capacity).
>
> I think Joanne has mentioned that her customers have a use case for
> multi backing ids per passthrough file and I assume this would be a pretty
> simple map, so that sounds pretty darn close to famfs already.

TBH, I thought that fuse-iomap is just going to be a generalization of
the passthrough interface.  At this point it seems like it's trying to
do quite a bit more.

> If we are being honest, then we need to develop features that users need
> and if users need features, there are usually employers willing to pay for the
> feature development and maintenance, if we let employers know that this is
> what it takes to get their users what they need.

I fell that this is a "politically charged" topic.

Let's just say that maintainability is very important in big features
like this.  Even deep pocketed employers can go broke or change their
priorities, so we need code that can be understood by at least one
additional person with a different background.  I think that would be
a good enough guarantee that the code is not going to be a nightmare
to maintain.

Thanks,
Miklos

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

[Darrick J. Wong]

On Tue, May 12, 2026 at 11:52:53AM +0200, Miklos Szeredi wrote:
> On Mon, 11 May 2026 at 19:18, Amir Goldstein <amir73il@gmail.com> wrote:
> 
> > IMO, FAMFS sits somewhere between PASSTHROUGH and IOMAP.
> > The simple nature of the maps, the fact that famfs maps are const and
> > queried at file open time makes me think that famfs is much closer to
> > PASSTHROUGH than it is to IOMAP (in its full capacity).
> >
> > I think Joanne has mentioned that her customers have a use case for
> > multi backing ids per passthrough file and I assume this would be a pretty
> > simple map, so that sounds pretty darn close to famfs already.
> 
> TBH, I thought that fuse-iomap is just going to be a generalization of
> the passthrough interface.  At this point it seems like it's trying to
> do quite a bit more.

To me it's always been more about exposing to fuse servers the same
local filesystem file IO paths that in-kernel filesystems can use.

> > If we are being honest, then we need to develop features that users need
> > and if users need features, there are usually employers willing to pay for the
> > feature development and maintenance, if we let employers know that this is
> > what it takes to get their users what they need.
> 
> I fell that this is a "politically charged" topic.
> 
> Let's just say that maintainability is very important in big features
> like this.  Even deep pocketed employers can go broke or change their
> priorities, so we need code that can be understood by at least one
> additional person with a different background.  I think that would be
> a good enough guarantee that the code is not going to be a nightmare
> to maintain.

I can't credibly say much of anything to this right now. :(

--D

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

[Darrick J. Wong]

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
>