Benchmarks
Benchmarks
Agent workloads
How does it do on the work agents actually do?
fs-bench
Head to head with Cloudflare Computer on Computer's own twelve-scenario filesystem benchmark, run unchanged on the same image.
- 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)
LayerFS v1.0.0
5.20 s
1.71×
Computer
8.88 s
LayerFS faster in 10 of 12 scenarios · one sample each
See the comparison
dsh-dedup
The whole history of a real project, 157 snapshots, kept as mountable Commits, against Btrfs snapshots of the same trees.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Against
- Btrfs snapshots of the same trees (2026-09-09); Git 2.47.1 pack
- Store
- Disposable · depth 16/8/8 · one construction worker
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 6.0–12.6 (1 min)
LayerFS v1.0.0
100.1 MB
19.9×
Btrfs + zstd
1,994.6 MB
157 snapshots · 4.94 GB of trees · every Commit mountable, 156/156 read back
See the storage
fs-bench-pro
Agent filesystem workflows on a real Store: Branches, edits, dedup, history and mixed load.
- LayerFS
- reference implementation at 823f556ca (retired R9c)
- Harness
- final3 seed-1 matrices, --setup clone
- Host
- 14 CPUs · load 6.7–8.8 (1 min)
- Image
- layerfs-bench-infra sha256:2bd697b9… · SQLite 3.51.0
latest run v0.1.6 · 36 cases · 36/36 proofs pass
3 releases measured
Correctness
Does it behave like a real filesystem?
pjdfstest
POSIX conformance: 238 test files and 8,798 assertions, LayerFS against the kernel’s own overlayfs in the same Sandbox.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- pjdfstest 85a8aea9 (classic C suite), as uid 501
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 6.3–15.8 (1 min)
LayerFS v1.0.0 vs kernel overlayfs
0 unexpected
reference passes kept
76%
- FIFO and UNIX socket nodesThree node types
- Set-id and sticky bits for the ownerPortable mode bits
- atime kept apart from mtimeOne stored time
- ctime on chmod, link, unlink, renameOne stored time
every LayerFS-only failure is a deliberate format limit · 238 files · as uid 501
See the limits
fsx
xfstests' file exerciser: millions of random reads, writes, mapped I/O and truncates, every byte checked against a model.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- xfstests ltp/fsx at 22348afe338c
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 7.5–14.9 (1 min)
LayerFS v1.0.0
14 / 14 PASS
ops checked
3.06 M
0 miscompares · 256 KiB–64 MiB files · mmap and O_DIRECT · reference 14/14
fallocate is outside LayerFS's FUSE surface by design (6 ops off)
See every run
fsstress
xfstests' stress generator: random concurrent operations from four processes, then the Workspace committed, remounted and compared entry by entry.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- xfstests ltp/fsstress at 22348afe338c
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 5.9–6.7 (1 min)
Commit → remount → compare
3,755 / 3,755
entries identical
0 diffs
5.21 GB captured by one Commit in 4.9 s · every run exit 0
5 call kinds outside the format by design: xattrs, fallocate, RENAME_EXCHANGE, …
See the proof
Performance
How fast are everyday file operations?
smallfile
Small-file operation rates: 100,000 files of 4 KiB created, read, appended, renamed and deleted by four threads.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- smallfile aa2519de · 4 threads × 25,000 × 4 KiB
- Baseline
- libfuse passthrough_ll 3.14.0, a sibling container on the same VM
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 6.7–11.5 (1 min), three-arm run
LayerFS v1.0.0
9 / 9 PASS
Commit, 100k files
10.4 s
LayerFS ÷ FUSE baseline (libfuse passthrough_ll) · faster in 9 of 9
See every operation
mdtest
Metadata rates from the IOR suite: create, stat, open and remove files and directories with 1 and 4 MPI processes.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- IOR mdtest f1172add · Open MPI 4.1.4, 1 and 4 procs
- Baseline
- libfuse passthrough_ll 3.14.0, a sibling container on the same VM
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 7.9–15.7 (1 min), three-arm run
LayerFS v1.0.0
9 / 9 exit 0
Commit, 20k files
2.6 s
LayerFS ÷ FUSE baseline (libfuse passthrough_ll) on create, rename and remove · the baseline did not finish 2 cases
See every phase
fio
Data I/O: sequential and random, buffered and direct reads and writes, bandwidth, IOPS and latency.
- LayerFS
- core at main e5c7aaae05, through the JS SDK
- Tool
- fio 3.33 · psync, iodepth 1, 20 s per job
- Baseline
- libfuse passthrough_ll 3.14.0, a sibling container on the same VM
- Reference
- kernel overlayfs, the same Sandbox's own /tmp (no FUSE)
- Host
- arm64 Mac · Docker Desktop, linux/arm64, 8 CPUs, 8.3 GB
- Load
- 6.5–19.9 (1 min), three-arm run
LayerFS v1.0.0
9 / 9 PASS
O_DIRECT random read
1.49× FUSE
LayerFS ÷ FUSE baseline · cache-served rows and fsync left out
See every job
How every suite is measured
One sample
Each case runs once, seed 1. No best-of, no repeats of an unchanged treatment.
Cold where it counts
Setup is cloned, never measured; a warm cache never credits a measured phase.
Speed beside storage
A smaller Store bought with a much slower run is reported, not hidden.
As recorded
FAIL stays FAIL, N/A never becomes zero, and every number links to its release record.