Checkpoint commit and atomic promotion
Turn completed immutable payloads into an unambiguous recovery generation with crash-safe publication and retry semantics.
On this page
The question for today
What you’ll understand
- Separate payload completion, manifest commitment, and latest-pointer promotion.
- Analyze coordinator crashes before and after a publication boundary.
- Use backend-specific durability and conditional-update guarantees without assuming a multi-object transaction.
A training process should never have to guess whether the newest directory is complete. Checkpoint publication is a small transaction built around a large collection of immutable data. The protocol writes and validates the collection first, establishes a complete generation second, and updates any discovery pointer under a defined concurrency rule. Each crash point needs an answer that preserves a previously usable recovery point.
Give every attempt a stable identity
Assign a unique generation and attempt identity before writing. Store new payload under immutable names or enforce a create-only policy so a retry cannot overwrite an older committed tensor. Writer acknowledgments must refer to that exact attempt and logical cut. Once required writes satisfy the backend contract, assemble a complete manifest binding their identities. An abandoned attempt may leave orphaned objects, but readers must not infer commitment from their presence. Garbage collection can reclaim them later under the same publication and reader-protection rules used for retained generations.
A discovery pointer such as latest is an optimization for finding a generation, not a replacement for its complete manifest. Resolve it to one immutable committed description, then validate that description. When a coordinator crashes after commitment but before pointer promotion, the old pointer can remain usable and the new generation can be discovered through an explicit repair path. When it crashes after a successful pointer update but before recording the response locally, retry must recognize the already performed transition rather than publish unrelated or incomplete state.
Use the guarantees the actual backend supplies
A filesystem namespace operation and persistence across power loss are different properties. Linux fsync documentation explicitly distinguishes flushing a file from ensuring its directory entry is persisted; the directory can need its own synchronization. The application must use a procedure supported by its filesystem and storage stack, check errors, and test crash behavior. A successful write into page cache, a closed file, or a barrier among workers should not be reinterpreted as proof of durable complete-generation publication on every backend.
Object stores require their own protocol rather than a filesystem rename assumption. Amazon S3 conditional writes can enforce create-only object names or compare an existing object version through an ETag condition. These operations apply to the specified object, not a transaction over every shard and manifest. A latest-pointer compare-and-set can prevent an observed concurrent overwrite, but still needs generation-order policy, retry handling, and immutable referenced data. An ETag used as a concurrency token is not a universal payload checksum or an authentication proof.
Rehearse interruption around the small critical transition
Test failure after each shard write, after manifest creation, during metadata synchronization, immediately before pointer update, and after the update but before acknowledgment. Readers should select a complete allowed generation or fail explicitly, never combine pieces from adjacent attempts. Concurrent coordinators need fencing or a conditional protocol so an older late writer cannot move latest backward unnoticed. If explicit rollback to an older generation is allowed, record it as a policy decision rather than treating generation order as an accidental timestamp comparison.
The Markov instrument offers only an abstract contrast between a monotone state and a reversible bit. Reset, set both p=1 and q=0, predict state-one probability one after one transition and thereafter, then Step twice. Separately Reset, set both p=1 and q=1, predict state-one probability zero after two transitions, then Step twice. The second chain alternates, so reaching state one once is not permanent. This probability model has no storage transaction, crash recovery, or consensus; an actual committed generation needs a protocol, not this animation.
Work it through
Recover around a pointer-update interruption
Generation 41 is committed and latest points to it. Generation 42 requires four payload objects. Three are ready when the coordinator crashes; after restart the fourth completes, the full manifest is committed, and latest is conditionally changed to 42, but its success response is lost.
At the first crash, three of four objects are insufficient. Generation 42 must remain unpublished and a reader can still use committed generation 41. A 75 percent payload count is not a valid substitute for completeness.
After all four objects and the complete manifest satisfy the contract, promotion to 42 is eligible. The condition must refer to the observed pointer version and the intended immutable generation.
When the response is lost, recovery reads the pointer and committed manifest. If the intended transition already occurred, the retry records that result; it does not rewrite 42 payload or assume that a timeout proves the pointer stayed at 41.
Crash safety depends on explicit states and idempotent recovery around publication. Payload completeness and discovery visibility remain separate facts.
The living notebook
Explore the model
Interactive lab · markov
A reversible state bit is not a commit protocol
Reset, set both p=1 and q=0, predict state-one probability one after two transitions, then Step twice. Separately Reset, set both p=1 and q=1, predict state-one probability zero after two transitions, then Step twice. Each Step is one exact chain transition; this model performs no filesystem, object-store, or consensus operation.
- P(state 1) at step 0
- 0%
- Stationary P(state 1)
- 60%
- Chain behavior
- Monotone convergence
Exact finite-step probabilities for a two-state chain starting in state 0, not sampled trajectories. Playback advances two transitions per second. When p = q = 0 every distribution is stationary; when p = q = 1 the chain alternates forever. A single zero transition creates an absorbing state. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forPublication requires a durable, recoverable protocol rather than merely observing a state label once.
Pause & reason
Check your understanding
Your turn
Try it yourself
A single-object conditional update succeeds for latest, but one referenced shard was never durably completed. Has conditional atomicity made the checkpoint safe?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Separate atomicity of one pointer from the invariant it must satisfy.
Compare with the solution
No. The pointer transition can be atomic while pointing to an invalid generation. The application violated the requirement that every dependency and the complete manifest be ready before promotion. Single-record conditional semantics do not provide a transaction or persistence guarantee for separately written payload objects.
Keep the idea
Take it with you
- Write immutable payload and commit complete metadata before promotion.
- Use filesystem or object-store guarantees at their documented scope.
- Make retries, concurrent coordinators, and lost acknowledgments recoverable.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.