Wiki

Stockage & GC

La vue Storage de l'onglet Files : tableau de bord de stockage par dépôt (taille, déduplication, croissance) et garbage collection, purge des vieilles révisions, chunks orphelins, phantom files.

Introduction

La vue Storage montre l'occupation disque d'un dépôt (un projet versionné sur le serveur) et fournit un outil de garbage collection (GC) pour récupérer de l'espace en purgeant les vieilles révisions et les données devenues inutiles.

Où la trouver Choisissez le dépôt dans le sélecteur de la rangée PROJECT, ouvrez l'onglet Files de cette même rangée, puis basculez sur la vue Storage avec les deux boutons Browse / Storage en haut de l'onglet. La vue Browse sert à parcourir les fichiers du dépôt ; tout ce que décrit cette page se trouve dans la vue Storage.

L onglet Files avec les deux boutons Browse et Storage en haut, Storage etant le bouton actif.

Accès et rôles

L'onglet Files et sa vue Storage sont accessibles au super admin et au project_admin sur les dépôts qu'il administre, y compris le lancement du GC. Les statistiques serveur globales et la licence sont, elles, réservées au super admin (ailleurs dans le panneau).

Les métriques

La vue Storage s'ouvre sur trois cartes, Total Size, Files / Revisions et Dedup Ratio. Viennent ensuite l'histogramme Growth (Last 30 Days), puis le tableau Largest Files. Le bouton de rafraîchissement, en haut à gauche, recalcule l'ensemble.

La vue Storage : les trois cartes Total Size, Files / Revisions et Dedup Ratio en haut, l histogramme Growth (Last 30 Days) en dessous, puis le tableau Largest Files avec ses colonnes Path, Size et Revisions.

Ce que chaque chiffre veut dire :

Total Size : la taille totale des fichiers, avec juste en dessous la taille compressée réellement occupée sur le disque.
Files / Revisions : le nombre de fichiers, et en dessous le nombre de révisions et de chunks.
Dedup Ratio (%) : la part d'espace économisée par le partage de chunks et la compression.
Growth (Last 30 Days) : la taille cumulée jour par jour. Survolez une barre pour lire sa date, sa taille et son nombre de révisions.
Largest Files : les 20 plus gros fichiers, avec leur taille et leur nombre de révisions.

Ces chiffres aident à repérer un dépôt qui gonfle : un fichier binaire volumineux souvent re-committé, ou une croissance anormale sur les 30 jours.

Garbage collection

Le bloc Garbage Collection se trouve en bas de la vue Storage. Il purge l'historique ancien selon deux paramètres :

Paramètre	Défaut	Rôle
Retention (days)	90	Âge en dessous duquel une révision est toujours conservée.
Min revisions to keep	5	Nombre de révisions récentes conservées par fichier, quel que soit leur âge.

Le GC est destructif et irréversible Les révisions purgées (au-delà de la fenêtre de rétention) ne se récupèrent pas, et Run GC ne demande aucune confirmation : le clic suffit. Lancez un Preview avant chaque exécution et vérifiez que les chiffres correspondent à ce que vous attendez.

1. Régler les deux paramètres

Saisissez Retention (days) et Min revisions to keep dans les deux champs, à gauche des boutons. Ils arrivent sur les valeurs par défaut du tableau ci-dessus, 90 et 5. Rappel : une révision n'est purgée que si les deux conditions sont réunies.

2. Lancer un aperçu avec Preview

Preview simule la purge sans rien supprimer. Un bandeau jaune apparaît sous les boutons : « Preview: X revisions would be deleted across Y files, Z phantom file entries would be removed ». C'est le moment de vérifier l'ordre de grandeur ; si le nombre vous surprend, remontez la rétention plutôt que de lancer.

Le bloc Garbage Collection : les champs Retention (days) et Min revisions to keep, les boutons Preview et Run GC, et le bandeau jaune de l apercu en dessous.

3. Exécuter avec Run GC

Le bouton rouge Run GC exécute la purge. Le bandeau vert de fin annonce « GC complete: X revisions deleted, Y orphan chunks cleaned, Z phantom file entries removed », les métriques du haut se rechargent, et l'exécution est journalisée dans l'audit.

Le bandeau vert GC complete affiche sous les boutons apres un Run GC : le nombre de revisions supprimees, de chunks orphelins nettoyes et d entrees fantomes retirees.

Ce que GC supprime

Vieilles révisions : celles plus anciennes que Retention (days) ET au-delà des Min revisions to keep plus récentes par fichier. Puis leurs chunks, s'ils ne sont plus référencés par aucune autre révision.
Chunks orphelins : les blocs de données que plus aucune révision n'utilise après la purge.
Phantom files : des lignes de fichier jamais réellement committées (chemin invalide ou entrée restée en suspens), au-delà d'une fenêtre fixe de 7 jours (non configurable).

Les marqueurs de suppression (tombstones) des fichiers effacés ou obliterés sont épargnés : ils servent à propager la suppression aux clients lors de la sync, et ne doivent donc pas disparaître.

Pièges courants

Le Preview annonce peu de choses

Normal si le dépôt est récent ou si l'historique tient dans la rétention. Le GC ne touche qu'aux révisions à la fois assez vieilles et au-delà des N dernières par fichier.

Preview et Run n'affichent pas les mêmes compteurs

Le Preview ne peut pas prédire le nombre exact de chunks et de liens révision-chunk supprimés : il ne rapporte que les révisions, les fichiers scannés et les entrées fantômes. Les chunks orphelins n'apparaissent qu'au Run.

Baisser la rétention pour récupérer de l'espace

Possible, mais vous perdez de l'historique. Sur un projet où l'on doit pouvoir revenir loin en arrière, gardez une rétention confortable et jouez plutôt sur les gros fichiers (voir la liste des plus gros fichiers, et le .uversionignore pour éviter de tracker des artefacts régénérables).