Repair and GC
GC plans and quarantine markers do not physically reclaim Strand bytes.
delete(&id).await marks a blob deleted in memory and appends a DeletionMarker to the metadata Strand. A failure between those actions can leave local and persisted views different. It does not erase old chunk payloads.
| Operation | Current behavior |
|---|---|
gc_sweep().await | Reads deletion markers, updates the in-memory index/refcounts and returns a GcPlan. It does not delete on-disk chunks. |
gc_apply(&plan).await | Appends QuarantineMarker records and increments a metric. It does not truncate or compact data files. |
compact().await | Calls sweep and apply; despite the name, it does not establish reclaimed filesystem bytes. |
repair_reindex().await | Rebuilds the metadata/chunk index and returns a report; called during store construction. It is not an automatic remote repair/fetch service. |
GcPlan contains candidates and total_reclaimable_bytes. The byte count is candidate packed data, not bytes actually freed. RepairReport contains checked_blobs, fixed_manifests, orphaned_chunks, recovered_bytes and errors; there are no missing or quarantined arrays.
Sweep mutates refcounts, so it is not a pure dry-run. The current implementation revisits deleted blobs each sweep and may decrement their referenced chunks again; do not treat repeated sweep calls as an idempotent accounting or deletion certificate.
