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.

Forcement, le débutant est passé à côté, puis après quelques années, le disque est full pendant un rebuild, ça casse le système et tu perds ton temps. C'est ballot, car c'est facile à éviter…

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 :

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.

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.

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

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

Pour limiter ce risque, Nix propose deux seuils :

1
2

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

Dans cet exemple :

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.

Voici la configuration que j'utilise actuellement :

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

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

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

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

Après un rebuild :

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.

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 :

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.