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

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

On Mon, Feb 02, 2026 at 02:51:04PM +0100, Miklos Szeredi wrote:
> I propose a session where various topics of interest could be
> discussed including but not limited to the below list
> 
> New features being proposed at various stages of readiness:
> 
>  - fuse4fs: exporting the iomap interface to userspace

FYI, I took a semi-break from fuse-iomap for 7.0 because I was too busy
working on xfs_healer, but I was planning to repost the patchbomb with
many many cleanups and reorganizations (thanks Joanne!) as soon as
possible after Linus tags 7.0-rc1.

I don't think LSFMM is a good venue for discussing a gigantic pile of
code, because (IMO) LSF is better spent either (a) retrying in person to
reach consensus on things that we couldn't do online; or (b) discussing
roadmaps and/or people problems.  In other words, I'd rather use
in-person time to go through broader topics that affect multiple people,
and the mailing lists for detailed examination of a large body of text.

However -- do you have questions about the design?  That could be a good
topic for email /and/ for a face to face meeting.  Though I strongly
suspect that there are so many other sub-topics that fuse-iomap could
eat up an entire afternoon at LSFMM:

 0 How do we convince $managers to spend money on porting filesystems
   to fuse?  Even if they use the regular slow mode?

 1 What's the process for merging all the code changes into libfuse?
   The iomap parts are pretty straightforward because libfuse passes
   the request/reply straight through to fuse server, but...

 2 ...the fuse service container part involves a bunch of architecture
   shifts to libfuse.  First you need a new mount helper to connect to
   a unix socket to start the service, pass some resources (fds and
   mount options) through the unix socket to the service.  Obviously
   that requires new library code for a fuse server to see the unix
   socket and request those resources.  After that you also need to
   define a systemd service file that stands up the appropriate
   sandboxing.  I've not written examples, but that needs to be in the
   final product.

 3 What tooling changes to we need to make to /sbin/mount so that it
   can discover fuse-service-container support and the caller's
   preferences in using the f-s-c vs. the kernel and whatnot?  Do we
   add another weird x-foo-bar "mount option" so that preferences may
   be specified explicitly?

 4 For defaults situations, where do we make policy about when to use
   f-s-c and when do we allow use of the kernel driver?  I would guess
   that anything in /etc/fstab could use the kernel driver, and
   everything else should use a fuse container if possible.  For
   unprivileged non-root-ns mounts I think we'd only allow the
   container?

<shrug> If we made progress on merging the kernel code in the next three
months, does that clear the way for discussions of 2-4 at LSF?

Also, I hear that FOSSY 2026 will have kernel and KDE tracks, and it's
in Vancouver BC, which could be a good venu to talk to the DE people.

>  - famfs: export distributed memory

This has been, uh, hanging out for an extraordinarily long time.

>  - zero copy for fuse-io-uring
> 
>  - large folios
> 
>  - file handles on the userspace API

(also all that restart stuff, but I think that was already proposed)

>  - compound requests
> 
>  - BPF scripts

Is this an extension of the fuse-bpf filtering discussion that happened
in 2023?  (I wondered why you wouldn't just do bpf hooks in the vfs
itself, but maybe hch already NAKed that?)

As for fuse-iomap -- this week Joanne and I have been working on making
it so that fuse servers can upload ->iomap_{begin,end,ioend} functions
into the kernel as BPF programs to avoid server upcalls.  This might be
a better way to handle the repeating-pattern-iomapping pattern that
seems to exist in famfs than hardcoding things in yet another "upload
iomap mappings" fuse request.

(Yes I see you FUSE_SETUPMAPPING...)

> How do these fit into the existing codebase?
> 
> Cleaner separation of layers:
> 
>  - transport layer: /dev/fuse, io-uring, viriofs

I've noticed that each thread in the libfuse uring backend collects a
pile of CQEs and processes them linearly.  So if it receives 5 CQEs and
the first request takes 30 seconds, the other four just get stuck in
line...?

>  - filesystem layer: local fs, distributed fs

<nod>

> Introduce new version of cleaned up API?
> 
>  - remove async INIT
> 
>  - no fixed ROOT_ID

Can we just merge this?
https://lore.kernel.org/linux-fsdevel/176169811231.1426070.12996939158894110793.stgit@frogsfrogsfrogs/

>  - consolidate caching rules
> 
>  - who's responsible for updating which metadata?

These two seem like a good combined session -- "who owns what file
metadata?"

>  - remove legacy and problematic flags
> 
>  - get rid of splice on /dev/fuse for new API version?
> 
> Unresolved issues:
> 
>  - locked / writeback folios vs. reclaim / page migration
> 
>  - strictlimiting vs. large folios

/me has no idea about these last four.

--D