Wiki

Storage & GC

Per-repository storage dashboard (size, deduplication, growth) and garbage collection: purging old revisions, orphan chunks, phantom files.

Introduction

The Storage tab shows a repository's disk usage and provides a garbage collection (GC) tool to reclaim space by purging old revisions and data that has become useless.

Access and roles

Available to the super admin and to a project_admin on the repositories they administer, including running GC. Global server statistics and the licence, on the other hand, are reserved for the super admin (elsewhere in the panel).

The metrics

The storage dashboard: deduplication ratio, 30-day growth histogram, and the top 20 largest files.

Total size and compressed size.
Deduplication ratio (%): the share of space saved through chunk sharing and compression.
Files / revisions / chunks.
Growth (last 30 days): a histogram of revisions per day.
Largest files: the top 20 by size, with their revision count.

These figures help spot a repository that is ballooning: a large binary file committed again and again, or abnormal growth over the past 30 days.

Garbage collection

The GC panel: retention and min-revisions fields, Preview and Run GC buttons, and a result banner.

GC purges old history according to two parameters:

Parameter	Default	Role
Retention (days)	90	Age below which a revision is always kept.
Min revisions to keep	5	Number of recent revisions kept per file, regardless of their age.

Two buttons:

Preview: simulates without deleting anything. Banner: "X revisions would be deleted across Y files, Z phantom entries would be removed". Always preview first.
Run GC: actually runs. Banner: "X revisions deleted, Y orphan chunks cleaned up, Z phantom entries removed". The run is recorded in the audit log.

GC is destructive and irreversible Purged revisions (beyond the retention window) cannot be recovered. Run a Preview before every Run GC and check that the figures match what you expect.

What GC deletes

Old revisions: those older than Retention (days) AND beyond the Min revisions to keep most recent per file. Then their chunks, if they are no longer referenced by any other revision.
Orphan chunks: data blocks that no revision uses anymore after the purge.
Phantom files: file rows that were never really committed (invalid path or an entry left pending), beyond a fixed 7 day window (not configurable).

Deletion markers (tombstones) for erased or obliterated files are spared: they serve to propagate the deletion to clients during sync, and so must not disappear.

Common pitfalls

Preview reports very little

Normal if the repository is recent or if its history fits within the retention window. GC only touches revisions that are both old enough and beyond the last N per file.

Preview and Run show different counters

Preview cannot predict the exact number of chunks and revision-chunk links deleted: it only reports revisions, scanned files and phantom entries. Orphan chunks appear only at Run time.

Lowering retention to reclaim space

Possible, but you lose history. On a project where you must be able to go far back, keep a comfortable retention and act instead on the large files (see the list of the largest files, and the .uversionignore to avoid tracking regenerable artifacts).