Le problème silencieux du store Nix

L’un des grands avantages de NixOS est sa capacité à conserver plusieurs générations du système. Une mise à jour ratée ? Un rollback permet de revenir instantanément à un état précédent.

Cette flexibilité a cependant un coût : l’espace disque.

À chaque mise à jour, à chaque compilation, à chaque nouvelle génération, le store nix accumule de nouveaux objets. Sur une machine disposant d’un SSD confortable, cela peut passer inaperçu pendant plusieurs mois. Sur un portable ou une machine virtuelle plus contrainte, la croissance devient rapidement visible.

J’ai pris l’habitude d’automatiser complètement la gestion de cet espace afin de ne plus avoir à exécuter manuellement les commandes de nettoyage.

Bien entendu, j’ai fait ça après avoir la base de données SQLite du store cassée pour cette raison…

Activer le nettoyage automatique

La première étape consiste à programmer le ramasse-miettes de nix.

1
2
3
4
5

nix.gc = {
  automatic = true;
  dates = "weekly";
  options = "--delete-older-than 30d";
};

Cette configuration demande à nix :

• d’exécuter automatiquement le garbage collector ;
• une fois par semaine ;
• en supprimant les générations âgées de plus de trente jours.

L’intérêt est de conserver un historique suffisamment long pour revenir en arrière en cas de problème tout en évitant l’accumulation de plusieurs mois, voire plusieurs années de générations inutilisées.

Optimiser le store

Le nettoyage n’est pas la seule source de gaspillage.

Il arrive fréquemment que plusieurs chemins du store contiennent exactement les mêmes données. nix est capable de détecter ces doublons et de les remplacer par des liens physiques.

L’activation est triviale :

1

nix.settings.auto-optimise-store = true;

Cette option permet souvent de récupérer plusieurs gigaoctets sur une installation utilisée depuis longtemps.

Le gain dépend fortement du nombre de paquets installés, mais comme l’opération est automatique et transparente, il n’y a généralement aucune raison de s’en priver.

Éviter la catastrophe pendant une compilation

Les compilations locales sont particulièrement gourmandes en espace disque.

Lorsque le SSD approche de la saturation, les symptômes sont parfois surprenants :

• Échecs de compilation ;
• erreurs d’écriture ;
• builds interrompus sans explication évidente ;
• comportements imprévisibles de certains outils ;
• la pire de toutes : la base SQLite cassée.

Pour limiter ce risque, Nix propose deux seuils :

1
2

nix.settings.min-free = 1000000000;
nix.settings.max-free = 3000000000;

Dans cet exemple :

• lorsque l’espace libre descend sous 1 Go, Nix déclenche automatiquement un garbage collection ;
• il tente ensuite de remonter jusqu’à environ 3 Go d’espace libre.

Le mécanisme agit comme une soupape de sécurité. Même après plusieurs semaines sans maintenance, le système dispose d’une chance supplémentaire d’éviter la saturation complète du disque.

La configuration complète

Voici la configuration que j’utilise actuellement :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  nix.gc = {
    automatic = true;
    dates = "weekly";
    options = "--delete-older-than 10d";
  };
  
  nix.settings = {
    auto-optimise-store = true;
    min-free = 1000000000;
    max-free = 3000000000;
  };
}

Vérifier le résultat

On reconstruit le système :

1

sudo nixos-rebuild switch

on peut vérifier la présence du timer :

1

systemctl list-timers | grep nix

et surveiller l’espace occupé par le store :

1

du -sh /nix/store

Sur une machine utilisée quotidiennement, la différence se remarque surtout après quelques mois. Le store reste à une taille raisonnable, les anciennes générations disparaissent progressivement et les compilations ont moins de chances d’échouer faute d’espace disque.

Conclusion

L’un des pièges de NixOS est que tout fonctionne tellement bien qu’on oublie parfois que le store continue de grandir en arrière-plan.

Quelques lignes de configuration suffisent pourtant à automatiser entièrement son entretien :

• Nettoyage hebdomadaire ;
• suppression des générations anciennes ;
• optimisation du stockage ;
• protection contre les compilations lorsque l’espace libre devient critique.

Une fois en place, on n’y pense plus. Et c’est probablement le meilleur compliment que l’on puisse faire à une tâche d’administration système.