jonnify·persistence /echo-persistence/tigris+fence/push-rollup

Module 9 · Dive 9.1

Push rollup.

Between uploads, a Volume may write the same page many times. Pushing every write would mean a storm of tiny objects, most immediately stale. So before upload the engine rolls up: it keeps only the latest version of each changed page, frames the result with Zstd, and writes one segment. Write some pages — repeating a few — and watch them collapse to a single object.

§1

Many writes, one segment

interactive
Coalescing the changed-page set. Each write appends to the log on the left; the rollup map in the center keeps the latest version per page as you go; rolling up frames those pages into one Zstd segment. Write repeats to see supersession.
write log (since last upload) rollup map · latest per page uploaded segment dedup frame + PUT
readout · Press write a few times — some pages repeat at higher versions, dimming the older writes. The rollup map keeps only the latest of each. Roll up and the changed pages become one Zstd segment, not a pile of tiny PUTs.
§2

Why coalesce before the wire

graft.design.md

Object stores reward few large writes and punish many small ones — each PUT has fixed overhead and the fence costs a round trip. Rolling up turns a burst of page writes into a single segment whose size is the count of distinct changed pages, not the number of writes, because a page written five times only needs its final version on the wire. Zstd then frames that segment so the bytes are compact. The effect compounds with the engines you have seen: the native engine’s commit-log outbox (Module 7) and the Rust engine’s flushes both push rollups, so a hot page that changes constantly still costs one page slot per upload, not one per change. The deduped, framed segment is exactly what a replica pulls (Module 6) and what recovery faults (Dive 9.3) — one object, latest versions only. Next, how that segment’s upload is made safe when more than one writer is involved.

§3

References & sources