FUSE status and plans [LWN.net]

LWN<br>.net<br>News from the source

Content Weekly Edition<br>Archives<br>Search<br>Kernel<br>Security<br>Events calendar<br>Unread comments

LWN FAQ<br>Write for us

Edition Return to the Front page

User:<br>Password: |

Log in /<br>Subscribe /<br>Register

FUSE status and plans

By Jake Edge<br>August 5, 2026

LSFMM+BPF

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

He began by noting that he feels he "is not a good maintainer".<br>There are two parts to being a maintainer, he thinks, "one is to keep<br>bugs out and the other is to let features in". He is good at the<br>first, but not at the second.<br>One way to address that is for FUSE to have a co-maintainer. "If someone<br>volunteers, I'd be very happy." There were some, perhaps joking, suggestions made by<br>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<br>Wong's iomap-based user-space<br>API for FUSE. That patch set is large, Szeredi said, increasing the<br>size of FUSE in the kernel by at least 30%. The FUSE-based<br>famfs patches from John Groves are much smaller and he hoped that some progress on those had been<br>made in the famfs session earlier in the<br>day. He also mentioned Joanne Koong's zero-copy<br>support for io_uring in FUSE, compound<br>commands from Horst Birthelmer, a file handle<br>user-space API for FUSE by Luis Henriques, the io_uring buffer size discussion that Bernd<br>Schubert led in the previous session, and Koong's large<br>folio support for FUSE. Meanwhile, Szeredi has been working on<br>restructuring and cleaning up the FUSE API.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have<br>access to all of LWN’s high-quality articles as soon as they’re<br>published, and help support LWN in the process. Act now and you can start with a free trial subscription.

He went into some details of the cleanup, starting with a separation of<br>the transport and filesystem layers that has made its way into the<br>upcoming 7.2 kernel. He has plans to do the same for character devices in user space (CUSE) and virtiofs. Beyond that,<br>he wants to provide multiple types of layers, citing existing network and<br>io_uring transports as examples needing better separation. He also wants to<br>pull the superblock operations out of inode.c into their own C<br>file and to split up the "very big" file.c into smaller<br>files based on the type of I/O being used. He<br>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,<br>like the FUSE kernel code, it has accumulated a fair amount of cruft. He<br>has started working on a clean-slate API, "which is currently very<br>slim" at around 2,000 lines of code, so 10% of the current FUSE API<br>size. It is called "fusex", for FUSE extended or experimental, and is available<br>in his FUSE tree. It has lots of limitations, since it only supports<br>local filesystems, which is exactly opposite of the network-filesystem<br>focus of the original FUSE, he said. It is synchronous-only as well, with no<br>support for asynchronous operations. While fusex is currently being used<br>as an experimental tree for adding various features that may eventually be<br>migrated into the main FUSE code base, he would like to see it turn into<br>"a new major version of the protocol".

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

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