FUSE status and plans

Ready to give LWN a try?

With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription, no credit card required, so that you can see for yourself. Please, join us!

Filesystem in Userspace (FUSE) maintainer Miklos Szeredi led a birds-of-a-feather (BoF) discussion about the subsystem at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. In it, he talked about maintenance challenges, proposed features and their status, and his plans for a new FUSE API. There is a lot of interest and activity in the FUSE community these days it seems.

He began by noting that he feels he "is not a good maintainer". There are two parts to being a maintainer, he thinks, "one is to keep bugs out and the other is to let features in". He is good at the first, but not at the second. One way to address that is for FUSE to have a co-maintainer. "If someone volunteers, I'd be very happy." There were some, perhaps joking, suggestions made by attendees, but no one stepped up to help co-maintain FUSE itself.

Features and cleanups

Szeredi moved on to a list of pending features, starting with Darrick Wong's iomap-based user-space API for FUSE. That patch set is large, Szeredi said, increasing the size of FUSE in the kernel by at least 30%. The FUSE-based famfs patches from John Groves are much smaller and he hoped that some progress on those had been made in the famfs session earlier in the day. He also mentioned Joanne Koong's zero-copy support for io_uring in FUSE, compound commands from Horst Birthelmer, a file handle user-space API for FUSE by Luis Henriques, the io_uring buffer size discussion that Bernd Schubert led in the previous session, and Koong's large folio support for FUSE. Meanwhile, Szeredi has been working on restructuring and cleaning up the FUSE API.

He went into some details of the cleanup, starting with a separation of the transport and filesystem layers that has made its way into the upcoming 7.2 kernel. He has plans to do the same for character devices in user space (CUSE) and virtiofs. Beyond that, he wants to provide multiple types of layers, citing existing network and io_uring transports as examples needing better separation. He also wants to pull the superblock operations out of inode.c into their own C file and to split up the "very big" file.c into smaller files based on the type of I/O being used. He encouraged others to raise their cleanup ideas as well.

The user-space API for FUSE is more than 20 years old at this point and, like the FUSE kernel code, it has accumulated a fair amount of cruft. He has started working on a clean-slate API, "which is currently very slim" at around 2,000 lines of code, so 10% of the current FUSE API size. It is called "fusex", for FUSE extended or experimental, and is available in his FUSE tree. It has lots of limitations, since it only supports local filesystems, which is exactly opposite of the network-filesystem focus of the original FUSE, he said. It is synchronous-only as well, with no support for asynchronous operations. While fusex is currently being used as an experimental tree for adding various features that may eventually be migrated into the main FUSE code base, he would like to see it turn into "a new major version of the protocol".

Ted Ts'o raised a "somewhat related" problem with FUSE filesystems being used on non-Linux platforms. In particular, there are users of the fuse2fs FUSE client on macOS and Windows; Wong has been working on extending it to use more recent FUSE features, Ts'o said, and encountering problems with macFUSE. Ts'o would like to see a simpler user-space API since he looked at the existing one and also noted the 20 years of history embodied in it. He would like his FUSE driver to work on macOS and Windows, but realizes that might take a fair amount of coordination from developers on the other operating systems with the Linux FUSE project, which may not be happening. Szeredi noted that the last he heard from the macFUSE developers was 15 years earlier, so there is no real coordination.

Schubert said that he had been working on some libfuse problems that occur on the BSDs and he believes that macFUSE is based on libfuse. It is difficult to run the libfuse tests on the BSDs, and he does not have or want a BSD system; some BSD developers are working on a virtual machine running the OS so that the tests can be run, but he does not think there is any similar effort going on with macFUSE. Because of Apple's kernel-code restrictions, he said, the current approach is to mount a filesystem as NFS and use a FUSE-to-NFS translation layer. Due to those restrictions, he thought that native macFUSE development had ceased.

Ts'o said that he was running native macOS FUSE on his laptop using macFUSE. The problem is that Apple requires a signed kernel extension, so only a single developer can build a binary from the macFUSE source code on GitHub. Anyone who wants to use macFUSE must obtain the binary from the Apple store, he said; there may be ways for others who want to work on the code to register with Apple so they can run it locally on their laptop, however. Schubert said that FUSE-T is the project he was talking about, which Ts'o was not familiar with. Ts'o does have interest in making fuse2fs work on macOS and also has access to BSD virtual machines, so he may be able to help with some of that testing.

Sub-maintainers

Szeredi noted that he thought some of the pending FUSE features, such as iomap, file handles, and compound command support, should go into fusex, rather than the existing FUSE implementation. He also thought it would make sense for FUSE to have sub-maintainers for some pieces, such as the io_uring path; he laughingly noted that Schubert already had too much on his plate but had volunteered to sub-maintain FUSE io_uring. Schubert said that he always looks at patches affecting that path now and would like to be notified directly when changes are made to it, but Christian Brauner cautioned that it was unlikely that changes like the recent kmalloc() conversion would be copied to him even as a sub-maintainer.

Brauner also suggested that Koong should consider being an io_uring sub-maintainer. She somewhat hesitantly agreed, but had a more general concern that she wanted to bring up. She would like the FUSE development community to get more guidance from Szeredi about what is maintainable, especially with regard to user-space APIs, which are difficult to change. He has decades of experience that many newer FUSE developers lack, she said. Another attendee noted that sub-maintainers will only be effective if Szeredi defers to their judgment; Szeredi agreed, noting that he is not able to keep all of FUSE in his head anymore, so he has deferred things like FUSE io_uring to others.

User-space API is an important thing to get right, Szeredi said. Brauner agreed and noted that kernel developers "suck at this", but noted that he thinks that developers in the virtual filesystem (VFS) layer have gotten better in recent times "because we are closely in sync with the actual users". That helps with better APIs but also helps API adoption; "oftentimes you can design APIs that are just ignored by user space because they're not practical".

Brauner noted that the recent focus on extensibility in VFS APIs has been beneficial. Once a new feature has been implemented, interesting ideas for extensions arise; being able to easily accommodate them "has been invaluable in my experience". He noted that io_uring was another example where extensibility was baked in from the outset.

Amir Goldstein had already volunteered as a FUSE passthrough sub-maintainer but he seemed skeptical that adding more FUSE subsystem entries to the kernel MAINTAINERS file would be useful. Others disagreed, and Brauner noted that it may well be helpful for people's careers; the tooling, b4 in particular, makes good use of those entries. Szeredi added two new FUSE subsystems, io_uring and passthrough, along with the new maintainers; that change was merged for 7.2.

Schubert had suggested monthly or biweekly conference calls for FUSE, so Szeredi asked him to describe his thinking. There is a need to agree on the approach for features, Schubert said; currently, development can proceed for months until a patch review derails the feature. That leaves developers trying to explain to their management that they will need more time to develop a new set of patches. He suggested that designs be submitted to the mailing list before development begins; those designs could be discussed in the calls. Brauner said that he wished VFS developers would do that.

Fusex

Over the remote link, Wong asked about fusex and whether it was meant to work with the existing libfuse. Szeredi said, perhaps a bit hesitantly, that it was; Wong was hoping that switching his iomap work to fusex would not require changing any user-space code, but Szeredi could not promise that. He did not think that a lot of code was needed, but fusex is still lacking for some needed features.

Fusex is only for local filesystems, he reiterated, which means that the filesystem cannot change except through FUSE (and fusex). Doing so should not cause a crash, but the filesystem will not work correctly because fusex does not have the infrastructure to handle that case, which simplifies it greatly. It is simply a prototype, at this point, but if it continues on, it should add the ability to remotely change the filesystem "but in a much more sane way than it is currently done in the upstream FUSE".

Brauner asked if Szeredi thought of fusex as a replacement for the existing FUSE; Szeredi said that he did, but thought that the existing FUSE could never go away because fusex cannot be completely backward compatible. The two would share much of the same code, so the maintenance burden would not be huge; in fact, "getting rid of the corner cases and strange behaviors" should make overall maintenance easier.

Goldstein noted that the maintenance burden will need to include libfuse, which Szeredi agreed was the case. Schubert said that he is planning to start marking some libfuse functions as deprecated; hopefully filesystem developers will move away from them over time. Conversions away from using the deprecated functions could perhaps even be handled by LLMs, he said.

Schubert also asked about features, such as compound commands, which are being pushed to fusex; the companies that are developing those features may want to use them with the less-restrictive upstream FUSE. Szeredi said that he is not opposed to adding features to the main FUSE code base, but would like to merge fusex as a place to experiment and then features that are added to it can be merged back to regular FUSE. With that, the session ran out of time. Szeredi did post a summary of the session to the mailing list shortly after the summit.