FUSE Performance Overhead vs. Kernel Filesystem Modules

FUSE performance overhead versus kernel filesystem modules is a workload decision. For persistent, forkable agent workloads, the flexibility of a userspace filesystem can be worth its cost, while metadata-heavy jobs on fast storage may need kernel-module performance. FUSE’s higher per-operation costs matter when those operations govern the work.

How FUSE works and where its overhead comes from

FUSE puts filesystem logic in a userspace daemon. That boundary adds three costs to operations that cannot be cached: context switches, memory copies, and single-queue serialization. Each uncached request crosses the kernel-to-userspace boundary twice, once to the daemon and once back. Those crossings add interprocess communication overhead that a kernel filesystem module does not pay. Even a tiny request has to make the trip.

Data movement adds a separate bill. FUSE cannot share buffers directly between the kernel and userspace, so it has to copy data each time it crosses. Those copies can dominate high-throughput workloads, where moving bytes becomes a substantial part of the work. Meanwhile, the FUSE driver serializes requests through one dispatch queue to the daemon. Adding cores does not raise filesystem throughput at the same rate, because more workers still have to pass through the same turnstile.

RFUSE, published at FAST '24, identifies that queue as a structural scalability limiter. Its replacement uses per-core ring buffers and brings throughput near kernel parity on high-performance devices. That result helps separate the cost of userspace filesystem logic from the cost of the interface carrying its requests. Vangoor et al. likewise concluded that userspace filesystems can run in production, but their applicability depends on the expected workload. Structural overhead is predictable enough to reason about.

What the overhead actually looks like across workload types

At one end of the performance range, the kernel page cache absorbs most reads. For cached data, the userspace daemon is not consulted at all, so FUSE adds near-zero overhead. A read-heavy workload with stable data can therefore behave very differently from one that repeatedly misses cache. Performance depends on how often an operation must leave the kernel and how much work accompanies that trip.

Metadata-heavy workloads sit near the other end. Many small files, frequent directory traversals, and operations such as git clone generate repeated boundary crossings when requests miss cache. Bento shows the same filesystem running a factor of seven slower on git clone through FUSE than as a native kernel filesystem. Large data transfers expose a different limit when fast storage and many cores outpace the dispatch queue. Vangoor et al. show how FUSE can leave some of the storage bandwidth unused on data-intensive workloads.

Cong Wang et al.’s 2026 BranchFS analysis reports that regular FUSE mode, with file descriptor caching, reaches 19 percent of native read throughput, with the kernel-to-userspace roundtrip causing the gap. Yet write throughput on ephemeral branches slightly exceeds native performance because BranchFS treats fsync as a no-op during exploration and avoids SSD sync cost. That is a different durability choice, showing how operation semantics can reverse the expected performance penalty.

Why kernel-module performance is genuinely necessary for some workloads

When metadata traffic, fast storage, and high concurrency meet, FUSE’s costs compound. On modern NVMe and high-core-count hosts, the kernel-side queue can saturate before the storage device does. Faster hardware then exposes the bottleneck. RFUSE was motivated by precisely this mismatch between FUSE’s 2001-era design and current hardware. Tuning around a queue is not the same as removing it.

Build systems, test runners, and package installs can cause metadata storms as they run thousands of operations on small files. Every cache miss brings the context-switch and communication costs back into play. When those operations take up most of a CI/CD or agent coding loop, kernel-module performance can be needed to get the job done. An agent label does not exempt a workload from filesystem physics. If filesystem operations govern completion time, their overhead belongs near the top of the architectural decision.

The kernel alternative has its own price. To build a traditional kernel filesystem, developers need to know the page cache, memory management, and block layers in depth, and C is the language they can use in practice. A bug can panic the system, iteration requires a reboot or module reload, and only root can load the module. Bento offers a middle path with safe Rust, near-native VFS performance, and live upgrades, but teams still have to decide how to deploy it. Kernel-module speed is real and sometimes necessary, while the development and operational costs explain why it is not the automatic winner.

Where FUSE's flexibility wins: agent sandboxes with persistent, forkable state

A coding agent installs a dependency, writes a file, runs a test, reads the failure, edits, and runs again. Each step depends on what the previous step left behind, so coordination can dominate the work. Fast checkpointing and branching are how storage designs around that need. Here, the useful unit of progress is a recoverable attempt.

BranchFS provides research context for this trade. It creates branches in sub-350 µs no matter how large the base filesystem is, commits small changes with under 1 ms of overhead, and runs without root privileges. Its branch context has copy-on-write isolation along with filesystem views and process groups that are independent of one another. A structured fork/explore/commit-or-abort lifecycle uses first-commit-wins resolution to invalidate sibling branches, while nested contexts support hierarchical exploration. The userspace boundary enables this unprivileged design, whereas a kernel-level implementation would require privileged infrastructure.

Shepherd, from Northeastern & Stanford, extends the pattern to full execution traces. Each action by an agent becomes a Git-like commit, each fork becomes a branch, and an earlier agent-environment state can be brought back. That requires state management beyond a stateless or purely kernel-managed filesystem. Persistence also has to outlive sandbox restarts, because an agent cannot compound work across sessions if hibernation erases installed packages and partially written files. A fast scratch space that forgets everything is still a scratch space, just with very quick reflexes.

The BranchFS write result shows how ephemeral exploration can favor fast branching over sync durability during iteration. For persistent, forkable disks, the relevant question is whether checkpointing, branching, and storage flexibility outweigh metadata penalties in the actual workflow. Coding agents that spend most of their time in package installs may still hit the kernel-performance case.

The object-store case: where FUSE's semantic gaps matter more than its speed gap

An interface that looks like a filesystem may behave differently from what ordinary file tools expect. FUSE-based object-store adapters can impose whole-object work on small edits, depending on their write model. The legacy staged-write approach downloaded an entire object when modification began and uploaded the full object on close or fsync. Streaming writes do away with full local staging, but write semantics still need to be checked alongside throughput charts.

Some FUSE layers mount an existing bucket as a POSIX filesystem without migrating the data, leaving the bucket as the source of truth. How faithfully they implement POSIX, and when writes reach the bucket, varies by implementation.

Avoiding migration should not be confused with eliminating FUSE’s kernel-to-userspace memory copies. These are different layers of the system, and a no-migration storage design does not cancel interface overhead. What a real POSIX interface offers agents is familiar behavior for tools they already use. Models trained heavily on bash and file tools can work with large datasets without treating object-store semantics as another abstraction to navigate.

An NFS-based bucket filesystem takes another approach, but it cannot take the place of the others at every layer of the architecture. Amazon S3 Files bypasses FUSE and mounts a general-purpose S3 bucket as an NFS filesystem accessible from the compute environment. Yet access through two interfaces still creates coordination questions. Its flock support provides mutual exclusion across filesystem clients, but S3 API access bypasses those locks, leaving simultaneous filesystem and API writes unprotected by locking.

Isolation requirements that shape which filesystem architecture is viable

The sandbox’s isolation boundary narrows the filesystem choices before performance enters the discussion. Standard containers share the host kernel, so a filesystem bug or malicious syscall from agent-generated code can affect other tenants. A kernel-module filesystem in that setting is a shared risk. Containers provide process-level isolation and are suitable only for trusted workloads in this taxonomy. Putting filesystem logic in userspace offers a containment layer, but it is not a replacement for choosing the right sandbox boundary.

Firecracker microVMs provide hardware-enforced isolation with a dedicated kernel per sandbox and boot in roughly 125 ms. That dedicated kernel makes a per-sandbox kernel-module filesystem viable without sharing it with sibling sandboxes. gVisor takes another route by intercepting syscalls in the Sentry, its Go-implemented Linux-compatible kernel. Filesystem operations are re-implemented at that boundary, and incomplete syscall emulation can cause compatibility issues with some Linux software. These approaches change both the trust boundary and the filesystem behavior available inside it.

Network access and credentials add constraints that neither FUSE nor a dedicated kernel automatically resolves. A 2026 Sandlock paper found that firejail and bubblewrap do not natively expose HTTP method/path-level access control, and a filesystem daemon with outbound access can become an egress vector. Secrets injected as environment variables are readable by processes inside the sandbox, including a FUSE daemon. Brokering credentials at the network boundary rather than passing them to code is the safer architecture. A cloud filesystem should thus be chosen as part of the plan for tenant isolation and credential handling.

A decision framework: matching filesystem architecture to workload conditions

Choose FUSE when the workload benefits more from flexibility than from minimizing every uncached operation. Stable, read-heavy data served from kernel page cache is a strong fit, as are unprivileged copy-on-write branching and rollback. Agent infrastructure that needs persistent, forkable state makes this trade concrete, as BranchFS and Shepherd demonstrate. A POSIX interface over object storage without migration is another reason to accept the cost, provided the interface supplies the required semantics. Userspace development also allows standard debugging tools, language choice, and reloads without rebooting.

Choose a kernel-module filesystem, or a near-kernel approach such as Bento, when high-concurrency metadata operations dominate and their latency materially affects the job. Fast NVMe and many cores add to that case because a single dispatch queue can leave hardware that has been paid for sitting idle. A dedicated-kernel sandbox makes kernel-module deployment more viable, but the development cost still needs justification. Conversely, untrusted agent code and shared tenancy strengthen the case for isolating a userspace daemon from other tenants.

Emerging interfaces soften the divide without making all approaches equivalent. RFUSE’s research implementation uses per-core ring buffers to approach kernel throughput while leaving existing userspace filesystem code unchanged. FUSE support for io_uring merged in Linux 6.14 addresses context-switch overhead, while Darrick Wong’s patch set is working toward unprivileged userspace ext4 with kernel-level performance. These paths should be weighed by how ready they are for use and which bottleneck they tackle. The final judgment is simple enough to use under deadline pressure, which is to pay for kernel performance when the workload needs it, and accept predictable FUSE overhead when state management, semantics, and safer iteration deliver more value.