Cluster DVR¶

The archive lives on streamer disks, but decisions about it are cluster-wide: space runs out on one machine and the stream moves to another. The Cluster DVR section answers two questions — how much archive storage you have, and what exactly fills it. Configuring the disks themselves is on the streamer page; recording and playing the archive is on Archive (DVR).

Streamers without DVR storage do not appear in the section at all — neither in the list nor in the totals. If nobody has storage configured, instead of a table you get "No streamer in the cluster has DVR storage configured."

Three buckets of used space¶

Used space is always split into three parts, and this is the main thing the section gives you. The same three buckets are computed for a disk, for a streamer and for the whole cluster:

Live — archive of the streams the streamer is required to record by its configuration. This is space well spent.
Orphan — archive that sits on the disk with no stream configuration behind it. Usually leftovers from deleted or relocated streams.
Unknown — the remainder of used space the catalog does not account for: files nobody has scanned, plus the filesystem reserve.

The usage bar runs left to right in exactly that order, so "space eaten by the wrong thing" shows up as a tail on the right.

A disk is not called a problem just because it is full. A disk filled with live archive is retention working as designed. The problem is a disk that is 98 % full while live archive accounts for less than 90 % of it: the space went to orphan or to unknown. Such disks get a red border, and streamers that have them sort to the top of the list.

Cluster overview¶

The top card holds the totals across every streamer: Capacity, live, orphan, unknown and the number of streamers with an archive, plus an overall usage bar.

Below it, one row per streamer: the name (a link to its disks), the usage bar, the disk count, the number of problem disks and "used / capacity". The data is re-read every 5 seconds.

The cluster overview: bucket totals and a streamer row with three disks

When the breakdown cannot be trusted¶

Telling live from orphan needs the stream map, and the map is not always there. The section says so plainly and falls back to showing used space as a whole instead of a wrong breakdown:

breakdown is being computed — the streamer recomputes catalog totals in the background and the first pass has not finished. Wait.
breakdown unavailable: configuration not applied — the streamer has not applied its recording configuration. Without the stream map the whole archive looks orphaned, so no breakdown is shown at all. What needs fixing is not the archive but config delivery — see Streamer diagnostics.
sizes still being computed: N blobs — some blobs have no computed size yet; their bytes count as unknown used space for now.

Do not act on cleanup until the breakdown is ready: orphan measured under an unapplied configuration is not orphan.

Disks of one streamer¶

Clicking a streamer name opens its disks as cards: path, the usage bar with the same breakdown, the used share and the capacity.

A streamer's disks: each with its own bar split into the three buckets

A disk with nothing to show on a bar shows its state instead:

disk unavailable — the streamer could not reach it.
not mounted — writes to the system partition are disabled — the archive path landed on the root partition rather than on a volume. The write is rejected on purpose: the mount check is on by default.

Archive cache¶

A streamer that serves someone else's archive can keep what it has read on its own cache disks — then a repeat request for the same part is served locally, with no trip to the source. That is how an edge is assembled: the cache disks are configured in the streamer settings, and caching is switched on for the stream.

A cache disk in a streamer's disk list is a different card, not an archive card full of zeroes. It has no three buckets of used space at all: it holds neither the current archive nor orphan, and a used share computed for it would be dishonest — it would reflect the write layout rather than the disk's health. The card shows instead:

Archive cache — the role label under the disk path.
Cache N / limit N — how much the cache has taken and how much it is allowed. With no limit set — no limit: the cache is bounded only by the volume's free space.
Hits/s — the rate of reads served by this disk. It is what exposes a dead disk that nothing lands on, and a skewed layout.

An edge streamer's disks: the cache disk card next to the archive ones

A red border and the line Free space is below the threshold: eviction is not keeping up with writes mean the cache is being written faster than it frees space. The cure is a cache limit, not manual cleanup.

On the cluster overview the cache has two readouts of its own:

Archive cache — the total cache volume across all streamers.
Cache hit rate — the share of archive reads served by the cache. The streamer row says the same thing shorter: Cache N and cache N %.

The hit rate is the share of hits among all archive reads: those served by the cache, those served by an archive disk, and those that went to a remote source. Live output and the background fetch of the next fragment are not part of it — otherwise the fetch would inflate the hit rate the better it worked.

If there is no cache in the cluster at all, these readouts are absent too: zeroes would read as "there is a cache and it does not work".

The mechanics of the cache itself — admission, eviction by last access, an edge running without archive disks — are described in the Sapsan documentation.

Rebuilding the index¶

The archive catalog and the disk contents can drift apart — after files were moved by hand, say, or after a restore from backup. The Rebuild index button makes the streamer walk its disks and add the blobs the catalog is missing.

The request is stored in the streamer configuration rather than sent to the streamer directly. That is why it survives the streamer being unreachable: if the machine is offline, the request waits for it to come back. It also gives the process a phase of its own — the request is stored, but the streamer has not picked it up yet.

The index rebuild card in its initial state

The states the card shows:

Index rebuild has never run. — the initial state.
Request stored, the streamer has not picked it up yet. — the request sits in the configuration and the streamer has not reached it.
Running: blobs N, added N, rescanned N. — the walk is in progress. Rescanned blobs are the expensive ones: their MP4 is re-read in full, and that is what explains the pace.
Last rebuild finished N ago, blobs added: N. — the walk is over.
Last rebuild was aborted N ago. — the walk did not reach the end.
The streamer configuration is unavailable: there is nowhere to store the request. — the button stays disabled while the configuration cannot be read.

The walk runs across disks in parallel. Stop aborts a rebuild in progress — the stop request is stored the same way, through the configuration.

The only thing that blocks a start is a walk already running. A rebuild does not interfere with recording or with archive playback.