Checkpoints

Understanding checkpoints

A checkpoint is a durable pin that preserves the current view of the namespace for readers. It effectively “reserves” the relevant manifest underlying resources so that a reader can safely query the current state without things moving underneath.

Checkpoint records have three possible categories of owners:

Owner	Created for	Released by
user	An operator-created administrative pin, labeled with name	maintenance checkpoint delete, its optional expiry, or namespace deletion
snapshot	An application-created read view	The snapshot lifecycle, lease expiry, or namespace deletion
fork	A target namespace that depends on its source thanks to copy-on-write	The fork lifecycle after the target no longer needs the source

Checkpoints are part of the underlying mechanism powering forking (see namespaces & forking), but they can also be used to enable bootstrapping of external indexes or mirrors and for broader use cases that need to reference a stable “snapshot” for long-running consistent reads.

Using checkpoints

The CLI can be used as follows:

loonfs maintenance checkpoint create --name nightly
loonfs maintenance checkpoint list
loonfs maintenance checkpoint delete {checkpoint_id}

Use --ttl-ms when creating a checkpoint that should expire automatically.