Repository navigation
fix(sandbox): clone the vz instance disk instead of copying it - #293
Merged
Merged
Conversation
Node's COPYFILE_FICLONE is a no-op on macOS: libuv opens the destination and calls fcopyfile(), so every provision wrote the full 8 GiB image out and expanded its sparse holes. Shell out to cp -c (clonefile) on darwin, falling back to copyFile. Measured on an M-series Mac: 8585ms and 8.0G allocated before, 3ms and shared extents after; first sandbox boot went from >60s (start timed out) to 2.0s. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Creating or resetting a macOS sandbox spent ~9s writing 8 GiB to disk, and the sandbox's first boot then crawled — often past the 60s start budget, failing with
sandbox server did not become healthy within 60000ms. Every boot after that was fine, which is what made it look intermittent.provision()intends a copy-on-write clone:On macOS that flag does nothing. libuv's
uv_fs_copyfileopens the destination and callsfcopyfile(); onlyclonefile(2)— which takes paths and requires the destination not to exist — can share extents. So it wrote the whole image out, and because the pristinerootfs.imgis sparse (8 GiB long, ~4 GiB allocated), the copy also filled its holes with real zeroes.Measured on this machine against the real image:
cp -cThe knock-on effect is what made it feel slow: the VM boots immediately after provisioning, so the guest competed with gigabytes of outstanding write-back for the very disk it was reading. Not the image size itself — the contention.
Fix
On darwin, shell out to
cp -c(clonefile), falling back tocopyFileif the clone can't happen;rmthe destination first, since clonefile requires it absent. Every other platform keeps the existing call.Verification
End-to-end on this machine, same VM and same image, only the disk differing:
sandbox starting→sandbox ready)bun test src/vz/provider.test.ts: 10 pass — existing create/reset coverage coincidentally exercises the dest-exists path.bun typecheckclean inpackages/codev-sandbox.No new unit test, deliberately. The suite runs under Bun, whose
copyFiledoes clone — so a sparseness assertion passes with or without this fix. I wrote one, confirmed it passed against the unfixed code, and removed it rather than ship false assurance. Pinning this properly needs the clone command injected likespawnImpl/fetchImplalready are; worth doing if this area changes again.Fork-only package, so no DIVERGENCES row. CHANGELOG entry under Sandbox.
🤖 Generated with Claude Code