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

[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