Module progress 

Per-pack index progress, published through a cheap shared counter.

The absorber (crate::git_ops) owns one IndexProgress per store and bumps its atomics as it goes — one fetch_add per resolved object, nothing locked, nothing formatted. A reader (gunnar’s dashboard tick, Admin.Stats) takes a Snapshot of every live counter through snapshot_all, which is what the row index rickard/linux 34% 4.7M/13.9M resolve 2.1 GB/s is drawn from.

Surviving a restart

The counter is process memory and does not survive one; the work does (the journal re-queues an unabsorbed pack on open). A pack that is being absorbed because the journal said so — rather than because a push in this process queued it — is marked resumed, so after a reboot the row reads index rickard/linux resumed 0% and an operator knows what the box is doing and why it started from zero.

The registry

A process-wide list of Weak<IndexProgress>: a store registers on open and its entry dies with it. Dead entries are swept on every snapshot, so the list is O(open stores) and no store has to remember to deregister.

Structs

IndexProgress

The counter. Every field is an atomic so the hot path pays one relaxed add.

ProgressTicker

A live progress row on the log, for as long as a pack is being absorbed.

Snapshot

One reader’s copy of a counter.

Enums

Phase

What the worker is doing to the pack right now.

Constants

TICK

How often the live progress row is logged while a pack is being absorbed.

Functions

snapshot_all

Every live counter, dead entries swept. Cheap: O(open stores), a few atomics each. active_only keeps the rows a dashboard shows; the full list is what a test or a stats call wants.