Wiki

Speicher & GC

Die Storage-Ansicht des Files-Reiters: Speicher-Dashboard pro Repository (Größe, Deduplizierung, Wachstum) und Garbage Collection, Bereinigung alter Revisionen, verwaister chunks, phantom files.

Einführung

Die Storage-Ansicht zeigt die Festplattenbelegung eines Repositorys (ein auf dem Server versioniertes Projekt) und bietet ein Garbage-Collection-Werkzeug (GC), um Platz zurückzugewinnen, indem alte Revisionen und nutzlos gewordene Daten bereinigt werden.

Wo man sie findet Wähle das Repository im Selektor der PROJECT-Zeile, öffne den Files-Reiter derselben Zeile und wechsle dann mit den beiden Schaltflächen Browse / Storage oben im Reiter zur Storage-Ansicht. Die Browse-Ansicht dient dem Durchsuchen der Dateien des Repositorys; alles, was diese Seite beschreibt, befindet sich in der Storage-Ansicht.

Der Files-Reiter mit den beiden Schaltflächen Browse und Storage oben, wobei Storage die aktive Schaltfläche ist.

Zugriff und Rollen

Der Files-Reiter und seine Storage-Ansicht stehen dem Super-Admin und dem project_admin auf den von ihm verwalteten Repositorys zur Verfügung, einschließlich des Startens von GC. Die globalen Serverstatistiken und die Lizenz hingegen sind dem Super-Admin vorbehalten (an anderer Stelle im Panel).

Die Metriken

Die Storage-Ansicht beginnt mit drei Karten, Total Size, Files / Revisions und Dedup Ratio. Es folgen das Histogramm Growth (Last 30 Days) und dann die Tabelle Largest Files. Die Aktualisieren-Schaltfläche oben links berechnet alles neu.

Die Storage-Ansicht: die drei Karten Total Size, Files / Revisions und Dedup Ratio oben, das Histogramm Growth (Last 30 Days) darunter, dann die Tabelle Largest Files mit ihren Spalten Path, Size und Revisions.

Was jede Zahl bedeutet:

Total Size: die Gesamtgröße der Dateien, direkt darunter die tatsächlich auf der Festplatte belegte komprimierte Größe.
Files / Revisions: die Anzahl der Dateien und darunter die Anzahl der Revisionen und chunks.
Dedup Ratio (%): der durch chunk-Sharing und Kompression eingesparte Anteil an Speicherplatz.
Growth (Last 30 Days): die kumulierte Größe Tag für Tag. Fahre mit der Maus über einen Balken, um sein Datum, seine Größe und seine Anzahl an Revisionen abzulesen.
Largest Files: die 20 größten Dateien mit ihrer Größe und ihrer Anzahl an Revisionen.

Diese Zahlen helfen, ein aufgeblähtes Repository zu erkennen: eine große, immer wieder neu committete Binärdatei oder ein ungewöhnliches Wachstum über die letzten 30 Tage.

Garbage Collection

Der Garbage Collection-Block befindet sich am unteren Ende der Storage-Ansicht. Er bereinigt die alte Historie anhand zweier Parameter:

Parameter	Standard	Rolle
Retention (days)	90	Alter, unterhalb dessen eine Revision immer erhalten bleibt.
Min revisions to keep	5	Anzahl der pro Datei erhaltenen jüngsten Revisionen, unabhängig von ihrem Alter.

GC ist destruktiv und unumkehrbar Bereinigte Revisionen (jenseits des Aufbewahrungsfensters) lassen sich nicht wiederherstellen, und Run GC fragt nicht nach einer Bestätigung: der Klick genügt. Führe vor jeder Ausführung eine Preview aus und prüfe, dass die Zahlen deinen Erwartungen entsprechen.

1. Die beiden Parameter einstellen

Gib Retention (days) und Min revisions to keep in die beiden Felder links neben den Schaltflächen ein. Sie starten mit den Standardwerten aus der Tabelle oben, 90 und 5. Hinweis: Eine Revision wird nur bereinigt, wenn beide Bedingungen erfüllt sind.

2. Eine Vorschau mit Preview starten

Preview simuliert die Bereinigung, ohne etwas zu löschen. Unter den Schaltflächen erscheint ein gelbes Banner: „Preview: X revisions would be deleted across Y files, Z phantom file entries would be removed“. Jetzt ist der Moment, die Größenordnung zu prüfen; wenn dich die Zahl überrascht, erhöhe die Aufbewahrung, statt auszuführen.

Der Garbage-Collection-Block: die Felder Retention (days) und Min revisions to keep, die Schaltflächen Preview und Run GC und darunter das gelbe Vorschau-Banner.

3. Mit Run GC ausführen

Die rote Schaltfläche Run GC führt die Bereinigung aus. Das grüne Abschlussbanner meldet „GC complete: X revisions deleted, Y orphan chunks cleaned, Z phantom file entries removed“, die Metriken oben werden neu geladen und der Lauf wird im Audit-Log protokolliert.

Das grüne GC-complete-Banner, das nach einem Run GC unter den Schaltflächen erscheint: die Anzahl der gelöschten Revisionen, der bereinigten verwaisten chunks und der entfernten phantom-Einträge.

Was GC löscht

Alte Revisionen: solche, die älter als Retention (days) sind UND über die Min revisions to keep jüngsten je Datei hinausgehen. Anschließend deren chunks, sofern sie von keiner anderen Revision mehr referenziert werden.
Verwaiste chunks: Datenblöcke, die nach der Bereinigung von keiner Revision mehr genutzt werden.
Phantom files: Dateizeilen, die nie wirklich committet wurden (ungültiger Pfad oder ein hängen gebliebener Eintrag), jenseits eines festen 7-Tage-Fensters (nicht konfigurierbar).

Die Löschmarkierungen (tombstones) gelöschter oder obliterierter Dateien werden verschont: sie dienen dazu, die Löschung beim Sync an die Clients zu propagieren, und dürfen daher nicht verschwinden.

Häufige Fallstricke

Preview meldet nur sehr wenig

Normal, wenn das Repository neu ist oder die Historie innerhalb des Aufbewahrungsfensters liegt. GC berührt nur Revisionen, die zugleich alt genug und jenseits der letzten N je Datei sind.

Preview und Run zeigen unterschiedliche Zähler

Preview kann die genaue Zahl der gelöschten chunks und Revision-chunk-Verknüpfungen nicht vorhersagen: es meldet nur Revisionen, gescannte Dateien und phantom-Einträge. Verwaiste chunks erscheinen erst beim Run.

Aufbewahrung senken, um Platz zurückzugewinnen

Möglich, aber du verlierst Historie. Bei einem Projekt, in dem man weit zurückgehen können muss, behalte eine großzügige Aufbewahrung bei und setze stattdessen bei den großen Dateien an (siehe die Liste der größten Dateien und die .uversionignore, um das Tracking regenerierbarer Artefakte zu vermeiden).