fio

Completeness and the Commit

Against a FUSE baseline

The like-for-like comparison: libfuse’s passthrough_ll (fuse-3.14.0) over a plain directory, writeback off, same jobs, same run. Where the filesystems themselves are compared, LayerFS is ahead in2 (randrw-70-30, rand-read-direct) and behind in 3 (seq-write, seq-read, rand-write). Rows the page cache answered on every arm, and the fsync row, are shown but not counted.

The reference is not like-for-like

Kernel overlayfs is the Sandbox's own overlayfs /tmp: the kernel's in-memory path, no FUSE. It is the ceiling for this host, not a peer:

• No FUSE hop

  The reference runs inside the kernel. Every LayerFS operation is a FUSE request to its daemon, a round trip every FUSE filesystem pays.

• Writes reach the daemon

  Kernel writeback caching is off under the FUSE contract, so each buffered write reaches LayerFS; the reference only copies into page cache.

• Every change is recorded

  LayerFS records each change so a Commit can capture it and mount it again later. The reference keeps nothing once the container goes.

• Buffered writes are the widest gap

  The kernel path finishes a buffered 4 KiB write by copying into page cache; with writeback off, every FUSE write, LayerFS’s and the baseline’s alike, is a round trip to a server.

• A ceiling, not a peer

  Ratios show the cost of those properties against the fastest local path on this host. The like-for-like comparison is the FUSE baseline, libfuse’s passthrough_ll, measured in the same run.

Job by job, all three arms

Bandwidth per job as recorded, each row on its own scale, with IOPS and completion latency (LayerFS / FUSE baseline / kernel overlayfs).

What it says

• Mixed and direct I/O lead

  Against the FUSE baseline, LayerFS is ahead on the 70/30 mixed job and on O_DIRECT random reads; on the mixed job its reads came from page cache while the baseline’s went to its server.

• Streaming writes trail

  Sequential and buffered random writes run below the baseline. LayerFS also records each write for the next Commit, work the baseline does not do; this run does not separate that cost.

• fsync by profile

  A Disposable Workspace promises no durability, so its fsync returns at once (p50 under 1 µs) where the baseline flushes to its backing. Shown, not counted.

• A sibling container

  A Sandbox cannot host a second FUSE mount (no-new-privileges, no user namespaces), so passthrough_ll runs in a sibling container from the same image, on the same VM and kernel; the tool runs as the same uid 501.

• Its own defaults

  passthrough_ll runs as root with no credential switch, up to 10 threads and a 1.0 s cache timeout. It keeps nothing beyond the directory: no recording, no Commit.

• Read with care

  One 20 s sample per job and arm at host load 6.50-19.89 (1 min). Finished files were removed from the two reference arms to keep the VM's page cache from overflowing. Docker Desktop on an arm64 Mac, LayerFS at main e5c7aaae05. An earlier two-arm run is in the data folder.

Data: benchmark/data/fio/v1.0.0/three-arm/ in the LayerFS repository (every job, ratios, the Commit, environment, receipts with fio's JSON, and the run record).