Repository navigation
vm: pin envelope blobs on every clone again (reverts #326) - #328
Merged
Merged
Conversation
Image GC rechecks a candidate blob under its digest lock by reading the VM records and then the snapshot records, in separate reads. Without the pin, a record-backed clone can prereserve after the VM read, finish, release the snapshot lease and see the snapshot removed before the snapshot read, so neither read holds the reference and GC deletes a blob the new VM boots from. The source lease keeps the snapshot record alive during the clone, not inside GC's recheck. The pin made the clone wait out the recheck; it costs 0.6 ms per sequential clone.
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.
Reverts #326. A record-backed clone needs the envelope pin after all.
Image GC rechecks a candidate blob under its digest lock through
pinnedElsewhere(cmd/core/init.go). It reads every hypervisor's VM records and then the snapshot records, as separatePinnedBlobIDsreads. Without the pin, this interleaving deletes a blob that a live VM still boots from:The source lease keeps the snapshot record alive for the length of the clone, but not across GC's two reads. With the pin, the clone waits on the digest lock until the recheck ends, and during the recheck the snapshot still holds the reference. Retries and later GC passes cannot restore a deleted blob, so this is permanent data loss.
The interleaving was found by a static review, not reproduced at runtime. #326 bought 0.6 ms per sequential clone (-1.65%) and about 1.7 ms per clone at 8-way.
The second commit corrects the comment above the pin. It claimed a record-backed clone's source already protects the blobs, and that claim led to #326. It is a one-line rewording, net zero comment lines.
Gates:
make lint(0 issues on linux and darwin),make fmt-check,asl,go build ./...on both GOOS, andgo test -race ./cmd/...on darwin and in a Linux arm64 container (8 packages ok each).