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

[Amir Goldstein <amir73il@gmail.com>]

[Fixed lsf-pc address typo]

On Mon, Feb 2, 2026 at 2:51 PM Miklos Szeredi <miklos@szeredi.hu> 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
>
>  - famfs: export distributed memory
>
>  - zero copy for fuse-io-uring
>
>  - large folios
>
>  - file handles on the userspace API
>
>  - compound requests
>
>  - BPF scripts
>
> How do these fit into the existing codebase?
>
> Cleaner separation of layers:
>
>  - transport layer: /dev/fuse, io-uring, viriofs
>
>  - filesystem layer: local fs, distributed fs
>
> Introduce new version of cleaned up API?
>
>  - remove async INIT
>
>  - no fixed ROOT_ID
>
>  - consolidate caching rules
>
>  - who's responsible for updating which 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

All important topics which I am sure will be discussed on a FUSE BoF.

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?

Thanks,
Amir.