What does saving an agent’s files cost on v349?

The save starts after the run ends. These samples place it outside the recorded run and compute intervals.

Run end to revision ready measures the wait after the run. Save phase total measures the save operation itself. They have different timing boundaries.

Each size has n = 5. The table shows p50 and max in milliseconds. We omit p90 and p99 at this sample size.

The payload contains random bytes from os.urandom, flushed with fsync. Saved-revision manifests confirm the byte counts and distinct payload hashes for each round. Added bytes include repository metadata. We did not download and independently hash the payload.

The phase components include parallel and child operations. Do not sum them to reconstruct the total. A missing component is unobserved, not zero.

At 64 MiB, round 3 executed the script twice. At 1,024 MiB, rounds 4 and 5 executed it twice. Each repeat overwrote the same payload path. The measurements retain the final saved file.

The split below gives sample counts and the full timing range for each execution count. The main table includes all final-file saves. These groups are too small for a percentile comparison.

The 1,024 MiB throughput run in round 1 appended an exit-status echo. It reported exit=0 and did not modify the timed CSV. No scored round was excluded.

Both /workspace and /tmp use node-local ext4 inside the VM. /workspace uses Firecracker Writeback caching. /tmp uses Unsafe rootfs caching: its guest fsync does not flush the host.

O_DIRECT bypasses only the guest cache. It does not establish a cold host read. These are cache-mode and dd process timings, not object-storage throughput. The save measurement above measures persistence work.

Each cell shows median [min, max], with n = 5 per size and path. Values are rounded to one decimal place. Throughput uses decimal MB/s. Small-file operations use 500 files of 4,096 bytes.

The 64 MiB /workspace writes formed two groups: rounds 1–3 measured 180.7 / 185.5 / 184.7 MB/s. Rounds 4–5 measured 30.5 / 59.8 MB/s. The cause is not established.

A canary run overlapped round 5 in the recorded timestamps. Round 4 preceded that canary. We did not calibrate cross-host clock skew, so timing overlap alone does not establish a cause.

The subsequent buffered read does not prove cache residency. The 1 MiB case is sensitive to process overhead. The throughput payload is zero-filled, while the save payload is random.

The driver used one host on the public internet, through Cloudflare, with one active disk-benchmark run at a time. All 40/40 pool claims were hits. Other production traffic could affect the timings.

Fresh VMs do not prove cold host caches. Plans and disk capacities differ across sizes. The 256 MiB and 1,024 MiB cases used power plan accounts. No restore after a cold copy was measured.

The finite sample does not establish population tail latency or a save-failure rate. No result is pooled across sizes, plans, or cache modes.

The downloads contain each save observation, the guest measurements, and the report data. Sample labels and round numbers are test labels. Infrastructure and account identifiers are omitted.

The measurement used scripts/bench/disk-save.sh and scripts/bench/disk-sample.sh. scripts/bench/disk-analyze.py produces the aggregate data. scripts/bench/disk-report.py produces the evidence report.

Run this command from the repository root to regenerate the page JSON and both download locations from the committed results. The repository is private. Public downloads are sufficient to inspect the measurements, but do not include the live harness or private infrastructure.