Re: [LSF/MM/BPF TOPIC] Where is fuse going? API cleanup, restructuring and more

[Joanne Koong <joannelkoong@gmail.com>]

On Mon, Feb 2, 2026 at 11:55 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
>
> On Mon, 2 Feb 2026 at 17:14, Amir Goldstein <amir73il@gmail.com> wrote:
>
> > All important topics which I am sure will be discussed on a FUSE BoF.

Two other items I'd like to add to the potential discussion list are:

* leveraging io-uring multishot for batching fuse writeback and
readahead requests, ie maximizing the throughput per roundtrip context
switch [1]

* settling how load distribution should be done for configurable
queues. We came to a bit of a standstill on Bernd's patchset [2] and
it would be great to finally get this resolved and the feature landed.
imo configurable queues and incremental buffer consumption are the two
main features needed to make fuse-over-io-uring more feasible on
large-scale systems.

>
> I see your point.   Maybe the BPF one could be useful as a cross track
> discussion, though I'm not sure the fuse side of the design is mature
> enough for that.  Joanne, you did some experiments with that, no?

The discussion on this was started in response [3] to Darrick's iomap
containerization patchset. I have a prototype based on [4] I can get
into reviewable shape this month or next, if there's interest in
getting something concrete before May. I did a quick check with the
bpf team a few days ago and confirmed with them that struct ops is the
way to go for adding the hook point for fuse. For attaching the bpf
progs to the fuse connection, going through the bpf link interface is
the modern/preferred way of doing this. Discussion wise, imo on the
fuse side what would be most useful to discuss in May would be what
other interception points do we think would be the most useful in fuse
and what should the API interfaces that we expose for those look like
(eg should these just take the in/out request structs already defined
in the uapi? or expose more state information?). imo, we should take
an incremental approach and add interception points more
conservatively than liberally, on a per-need basis as use cases
actually come up.

>
> > I think that at least one question of interest to the wider fs audience is
> >
> > Can any of the above improvements be used to help phase out some
> > of the old under maintained fs and reduce the burden on vfs maintainers?

I think it might be helpful to know ahead of time where the main
hesitation lies. Is it performance? Maybe it'd be helpful if before
May there was a prototype converting a simpler filesystem (Darrick and
I were musing about fat maybe being a good one) and getting a sense of
what the delta is between the native kernel implementation and a
fuse-based version? In the past year fuse added a lot of new
capabilities that improved performance by quite a bit so I'm curious
to see where the delta now lies. Or maybe the hesitation is something
else entirely, in which case that's probably a conversation better
left for May.

Thanks,
Joanne

[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1Z3mTdZdfe5rTukKOnU0y5dpM8aFTCqbctBWsa-S301TQ@mail.gmail.com/

[2] https://lore.kernel.org/linux-fsdevel/20251013-reduced-nr-ring-queues_3-v3-4-6d87c8aa31ae@ddn.com/t/#u

[3] https://lore.kernel.org/linux-fsdevel/CAJnrk1Z05QZmos90qmWtnWGF+Kb7rVziJ51UpuJ0O=A+6N1vrg@mail.gmail.com/t/#u

[4] https://lore.kernel.org/linux-fsdevel/176169810144.1424854.11439355400009006946.stgit@frogsfrogsfrogs/T/#m4998d92f6210d50d0bf6760490689c029bda9231

>
> I think the major show stopper is that nobody is going to put a major
> effort into porting unmaintained kernel filesystems to a different
> framework.
>
> Alternatively someone could implement a "VFS emulator" library.  But
> keeping that in sync with the kernel, together with all the old fs
> would be an even greater burden...
>
> Thanks,
> Miklos