# Performance Differences Between FUSE Mounts and Native Disk in Cloudflare Computer

> Explore Cloudflare Computer's FUSE mount vs native disk performance. Discover which excels at metadata ops and where RPC overhead causes slowdowns.

- Repository: [Cloudflare/computer](https://github.com/cloudflare/computer)
- Tags: performance
- Published: 2026-08-13

---

**Cloudflare Computer's FUSE-mounted filesystem at `/workspace` outperforms native ext4 disk for metadata-heavy operations but can be up to 40× slower for large sequential I/O due to content-addressed chunking and RPC overhead.**

Cloudflare Computer persists data by running a `computerd` process inside a **Durable Object** and mounting it via **FUSE** at `/workspace`. This virtual filesystem uses an in-memory inode store and a content-addressed blob store, creating fundamentally different performance characteristics compared to the container's native ext4 disk (`/var/tmp`) or temporary `tmpfs` volumes (`/tmp`).

## Benchmark Overview

The official benchmark suite in [`script/fs-bench.sh`](https://github.com/cloudflare/computer/blob/main/script/fs-bench.sh) evaluates three storage backends across realistic developer workloads:

- **`/workspace`** – The `computerd` FUSE mount backed by Durable Objects
- **`/tmp`** – Kernel tmpfs (in-memory, no persistence)
- **`/var/tmp`** – Container-native ext4 disk

The full results are documented in [`docs/19_performance.md`](https://github.com/cloudflare/computer/blob/main/docs/19_performance.md), measuring both metadata latency and raw throughput.

## Metadata-Heavy Operations

For filesystem metadata tasks—stat, rm, mkdir, find, and git operations—the FUSE mount leverages its **in-memory inode store** to outperform ext4 disk in most scenarios, though it cannot match raw tmpfs speeds due to RPC serialization.

**1,000 file stat operations:**
- **computerd (FUSE):** 1,971.9 ms
- **tmpfs:** 1,324.2 ms (1.49× faster)
- **ext4 disk:** 2,659.3 ms (0.91× slower than FUSE)

**1,000 file removals:**
- **computerd (FUSE):** 827.7 ms
- **tmpfs:** 322.7 ms (2.56× faster)
- **ext4 disk:** 1,281.8 ms (0.66× slower than FUSE)

**Git operations show the largest divergence:**
- `git init` + commit of 100 files takes **459.2 ms** on FUSE versus **40.3 ms** on tmpfs (9.56× slower) and **635.4 ms** on ext4 disk
- Shallow clone performance narrows to **1.30×** slower than tmpfs, with FUSE (549.1 ms) actually edging out ext4 disk (576.2 ms)

The inode store lives in RAM inside the Durable Object, explaining why `computerd` beats ext4 for tree traversals and file system metadata, as implemented in the core storage layers.

## Large Sequential File I/O

For bulk data movement, the **content-addressed chunking** architecture creates significant overhead. Every 512 KiB chunk written is hashed and stored as a blob (`CHUNK_SIZE` in [`packages/dofs/src/fs/writeFile.ts`](https://github.com/cloudflare/computer/blob/main/packages/dofs/src/fs/writeFile.ts)), introducing CPU and RPC costs.

**64 MiB sequential write:**
- **computerd (FUSE):** 230.6 ms
- **tmpfs:** 47.3 ms (4.87× faster)
- **ext4 disk:** 16.8 ms (16.93× faster)

**64 MiB pure read:**
- **computerd (FUSE):** 263.1 ms
- **tmpfs:** 8.3 ms (31.54× faster)
- **ext4 disk:** 8.5 ms (30.26× faster)

**64 MiB copy operations exhibit the worst overhead:**
- FUSE requires **1,037.2 ms**
- tmpfs completes in **37.4 ms** (27.75× faster)
- ext4 disk finishes in **39.8 ms** (40.46× faster)

The FUSE RPC boundary uses Cap'n Proto serialization (`packages/rpc`) between the container and Durable Object. While negligible for small metadata calls, this overhead dominates large sequential transfers.

## Real-World Workload: npm Install

A full `npm install` of the `cloudflare/sandbox-sdk` package demonstrates practical impact:

- **tmpfs:** 34.3 seconds
- **ext4 disk:** 63.9 seconds
- **computerd FUSE:** 124.7 seconds

The FUSE mount is approximately **2× slower** than native ext4 disk and **3.6× slower** than tmpfs for this workload. The ext4 baseline represents the more realistic comparison for everyday builds, as package installation involves mixed sequential I/O similar to the benchmark's large-file scenarios.

## Architectural Roots of the Performance Gap

Four design decisions in the Cloudflare Computer source code create these measurable differences:

1. **In-memory inode store** – Metadata structures reside in the Durable Object's RAM, accelerating `stat`, `mkdir`, and `find` operations beyond what disk-based ext4 can provide.

2. **Content-addressed chunking** – The [`writeFile.ts`](https://github.com/cloudflare/computer/blob/main/writeFile.ts) implementation hashes every 512 KiB chunk and stores it as a distinct blob. This enables **deduplication** and **incremental sync** across edge locations, but each chunk requires a hash computation plus RPC round-trip.

3. **Cap'n Proto RPC boundary** – All filesystem calls traverse the RPC layer defined in `packages/rpc`. Small metadata calls absorb this overhead, but bulk transfers amplify it.

4. **Native storage physics** – Container ext4 uses conventional block devices with kernel caching, while tmpfs bypasses block storage entirely. The FUSE mount cannot match raw tmpfs because it must serialize operations over the networked Durable Object boundary.

## Running the Official Benchmarks

Reproduce these metrics locally using the repository's benchmark tooling:

```bash

# Clone and build the workspace

git clone https://github.com/cloudflare/computer.git
cd computer
npm run build

# Execute the full filesystem benchmark comparing FUSE, tmpfs, and ext4

bash script/fs-bench.sh

```

The script sets `MOUNT=/workspace` for the FUSE target and `BASE=/tmp` for the tmpfs baseline, outputting timings identical to the performance documentation.

### Manual FUSE Mount Testing

Start the daemon manually and measure metadata operations:

```bash

# Inside a Cloudflare Container

npx @cloudflare/computer-tools start --mount /workspace

# Create 1,000 small files

mkdir -p /workspace/test
for i in {1..1000}; do touch /workspace/test/file-$i; done

# Benchmark metadata retrieval (fast due to in-memory inodes)

time stat /workspace/test/file-* > /dev/null

```

### Measuring Large File Throughput

Compare raw I/O across all three backends:

```bash

# Write 64 MiB to each storage type

dd if=/dev/zero of=/workspace/large.bin bs=1M count=64 oflag=direct
dd if=/dev/zero of=/var/tmp/large.bin bs=1M count=64 oflag=direct
dd if=/dev/zero of=/tmp/large.bin bs=1M count=64 oflag=direct

```

Timing these commands reproduces the "pure write" and "overwrite" ratios from the official benchmark suite.

## Summary

- **`/workspace` (FUSE)** excels at metadata-heavy developer tasks like `git status`, module resolution, and tree traversals, often outperforming ext4 disk
- **Content-addressed chunking** in [`packages/dofs/src/fs/writeFile.ts`](https://github.com/cloudflare/computer/blob/main/packages/dofs/src/fs/writeFile.ts) creates overhead that makes large sequential I/O up to 40× slower than native disk
- **Real-world builds** like `npm install` run approximately 2× slower on FUSE compared to ext4, and 3.6× slower than tmpfs
- The trade-off enables **global deduplication** and **cross-edge synchronization** through the Durable Object architecture
- Use `/var/tmp` for build caches and temporary artifacts requiring high-throughput sequential I/O, while `/workspace` remains optimal for source code and git repositories

## Frequently Asked Questions

### Why is the FUSE mount slower than native disk for large files?

The `computerd` filesystem splits every write into 512 KiB chunks, hashes each chunk for content-addressing, and stores them as individual blobs via RPC calls to the Durable Object. This hashing and network serialization overhead, implemented in [`packages/dofs/src/fs/writeFile.ts`](https://github.com/cloudflare/computer/blob/main/packages/dofs/src/fs/writeFile.ts), prioritizes deduplication and sync efficiency over raw throughput.

### When should I use `/workspace` versus `/var/tmp` in Cloudflare Computer?

Mount source code and git repositories at `/workspace` to leverage the fast in-memory inode store for metadata operations. Use `/var/tmp` for build artifacts, package caches, and large temporary files that require high sequential throughput, as the native ext4 disk outperforms FUSE for bulk data movement by up to 16×.

### How does the FUSE mount compare to tmpfs?

While both use memory, tmpfs bypasses all RPC boundaries and hashing logic. The FUSE mount must serialize operations through the Cap'n Proto layer (`packages/rpc`), making it 1.5× to 40× slower than tmpfs depending on workload, despite both being memory-backed for metadata.

### Can I disable content-addressed chunking to improve write speed?

No. The chunking mechanism is fundamental to the `computerd` architecture, enabling features like incremental synchronization and deduplication across Durable Object instances. The performance cost is the intentional trade-off for these distributed filesystem capabilities.