jonnify·persistence /echo-persistence/champ-accept-tier/the-checkpoint-dial

Module 2 · Dive 2.2

The checkpoint dial.

Champ snapshots every K records. That single number is two things at once: the loss window — exactly the records accepted since the last snapshot — and the throughput dial, because one fsync covers all K. Feed the gauge, watch the at-risk window fill and a snapshot fire, then change K and see both move.

§1

K is the loss window

interactive
The checkpoint gauge. The arc is the records accepted since the last snapshot. Add records; when it reaches K, a snapshot is fsync’d and the arc resets. Everything in the arc right now is what a crash would lose.
0 at risk / K = 1,000 0 K ✓ snapshot · fsync
readout · Add records. The arc is the at-risk window; reaching K fsyncs a snapshot and empties it. Raise K and the arc fills more slowly — fewer fsyncs, a larger window; lower K and it snapshots often — smaller window, more fsyncs.
§2

The same lever, named for Champ

graft.design.md

This is the spectrum’s one knob, wearing Champ’s clothes. Records-per-fsync from Module 1 is here called K, and because the structure is persistent (Dive 2.1) the snapshot it fsyncs is a reference, not a copy — so raising K is nearly free on the accept side and simply widens the window. There is no “right” K; there is the K your queue’s tolerable loss allows. The next dive answers the question this raises: when the window does take records, how does Champ get them back?

§3

References & sources