LayerFSv0.1.7 releases

Benchmarks

fs-bench

Cloudflare Computer's own filesystem benchmark: twelve shell scenarios over a mounted FUSE filesystem, from creating 1,000 files to a 100-file git commit. We run its frozen script unchanged against pinned Cloudflare Computer and against LayerFS v1.0.0, on the same image, one after the other.

LayerFS against Cloudflare Computer

vs Computer
KindAgent workloadsmixed workloadComputer’s own suite
LayerFSv1.0.0
Ran on
LayerFS
core at main e5c7aaae05, through the JS SDK
Against
Cloudflare Computer de87919a4
Host
arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
Image
sha256:66aeb6bb… (both sides)
Load
7.5 / 8.2 (1 min)

Totals

LayerFS v1.0.0

5.20 s

sum of the 12 scenarios · faster in 10 of 12

1.71×

less total time

Cloudflare Computer

8.88 s

computerd at de87919a4 · faster in 2 of 12

One sample per side, pair 20261019T195401Z, LayerFS at main e5c7aaae05. The sum is a convenience total, not an agent-turn duration.

Scenario by scenario

LayerFS grows left, Computer grows right; each row is scaled to its slower side, so the shorter bar is the faster one.

  1. create 1000 files◀ 3.38× faster
    413 ms
    1.40 s
  2. stat 1000 files◀ 1.57× faster
    1.07 s
    1.68 s
  3. rm 1000 files◀ 2.60× faster
    476 ms
    1.24 s
  4. mkdir tree (10x10x10)◀ 1.68× faster
    835 ms
    1.41 s
  5. find tree◀ 1.56× faster
    960 ms
    1.50 s
  6. write 64 MiB1.26× faster ▶
    160 ms
    127 ms
  7. copy 64 MiB1.70× faster ▶
    598 ms
    352 ms
  8. read 64 MiBtie (0.6 ms apart)
    178 ms
    179 ms
  9. pure read 64 MiB◀ 10.56× faster· warm
    7.4 ms
    78 ms
  10. pure copy 64 MiB◀ 1.07× faster· warm
    209 ms
    224 ms
  11. overwrite 64 MiB◀ 1.52× faster· warm
    111 ms
    169 ms
  12. git init + commit 100 files◀ 2.95× faster
    181 ms
    535 ms

Same workload, two systems

Shared by both: fs-bench.sh sha256 0e2004339a9269b88c2de451d56575957477bde16b96a10cf1837519e37230ef; 12 offline scenarios; REPS=1 WARMUP=0 RANDOMIZE_TARGETS=0 · image sha256:66aeb6bbf7fc… (node:22-bookworm-slim arm64, computerd, git 2.39.5, bash 5.2.15, gawk 5.2.1) · macOS 26.4.1 arm64; Docker Desktop 29.5.2, linux/arm64, kernel 6.12.76-linuxkit, 8 CPUs, 8.3 GB.

LayerFS v1.0.0Cloudflare Computer
How the script ransandbox.exec (@layerfs/sdk)docker exec
Runs as501:20 (Sandbox command identity)0:0
Setupproject.init, sandbox.create, branch.fork(bench, main), sandbox.mount(bench)computerd source CLI, FUSE_MOUNT=fuse, MOUNT_POINT=/workspace
Mount/workspaces/1 fuse layerfs noatime default_permissions,allow_other max_read=131072, writeback off/workspace fuse /dev/fuse relatime max_read=524288
Containerunprivileged Sandbox, /dev/fuse, CAP_SYS_ADMINprivileged, /dev/fuse, SYS_ADMIN, MKNOD, apparmor and seccomp unconfined
Filesystem daemonlayerfs-daemon sha256 431dc4f523fb6b65b52dc4eae0bf18bb45074b812c84c5023beccf6270c4cb97; cache_bytes 64 MiB, namespaces 16, pager_kib 1024computerd (auto_cache profile)
ClientJS SDK addon layerfs.node sha256 242b43844887e1335cecb60a891cdb8f57e72cd871a5a5866eb63607e8b6034f; Node 24.21.0 in layerfs-352-runtime:node24—
StoreDisposable/WAL/OFF Store on a fresh named volume; one-file project—
Host load (1 min)8.167.48
Whole collector command11.65 s12.96 s

How each side ran

LayerFS, only through the JS SDK

As an agent would: every step is a public @layerfs/sdk call, and the script runs through sandbox.exec as the Sandbox's user (501).

  1. project.init("/tmp/fs-bench-source")one README
  2. sandbox.create("bench", "fsbench", image)the Sandbox container and daemon
  3. branch.fork("bench", "main")its own Branch
  4. sandbox.mount("bench", "bench")/workspaces/1
  5. sandbox.exec(× 3)check, run fs-bench.sh, collect
  6. sandbox.unmount(…, discard)then sandbox.close

Cloudflare Computer, as its benchmark expects

computerd from the pinned commit's source CLI with its FUSE backend, mounted at/workspace in a privileged container. The script runs throughdocker exec as root, the owner of that mount.

Both sides run the same bytes of fs-bench.sh (hash-checked before each run), with one sample, no warm-up and a fixed order. Each scenario is timed inside the script, so how it was launched is outside every timer.

Read with care

  • One sample each

    On this host, single rows have moved by up to about 2× between runs. Close rows such as read 64 MiB are a tie, not a win.

  • Each as deployed

    Computer runs privileged with a larger max_read and auto_cache; LayerFS runs in a narrower Sandbox with writeback off. Kernel settings are not equalised.

  • Warm rows

    pure read, pure copy and overwrite read or rewrite what the scenario just wrote: warm-state behaviour, not cold reads.

  • Not the whole call

    Setup, mount, Commit and unmount are outside the timers. This is Docker Desktop on an arm64 Mac, not a native Linux host.

Data: benchmark/data/fs-bench/v1.0.0/ in the LayerFS repository (results, environment, raw receipts and the campaign record).