Le principe est séduisant : déclarer un disque de 500 Go qui n'occupe réellement que les 40 Go écrits. C'est l'allocation fine, et pour l'écriture elle tient parfaitement sa promesse.
Le problème est de l'autre côté. Vous supprimez 200 Go dans une machine virtuelle, vous regardez l'hyperviseur, et l'occupation n'a pas bougé d'un octet. Rien n'est cassé. Simplement, personne n'a prévenu la couche du dessous.
Supprimer un fichier ne libère rien
Une suppression est une opération locale au système de fichiers invité : l'entrée disparaît d'une table, les blocs sont marqués réutilisables pour ce système de fichiers. Aucun message n'est envoyé vers le bas.
Vu de l'hyperviseur, ces blocs ont été écrits au moins une fois, donc ils sont alloués. Il n'a strictement aucun moyen de deviner qu'ils ne contiennent plus rien d'utile. L'allocation fine alloue à la première écriture et ne désalloue jamais d'elle-même.
Pour récupérer l'espace, il faut une déclaration explicite : la commande TRIM, qui signifie « ces blocs sont libres, tu peux les reprendre ».
Une chaîne, et un seul maillon suffit à tout casser
C'est ici que la plupart des installations échouent, parce que la libération doit traverser toutes les couches :
- Le système de fichiers invité doit émettre les TRIM — soit en continu, soit par passe périodique.
- Le contrôleur disque virtuel doit savoir les transmettre, et l'option correspondante doit être activée sur le disque.
- Le format d'image ou le volume doit supporter la désallocation.
- Le stockage physique doit honorer la commande.
Il suffit qu'un seul maillon soit absent pour que rien ne remonte. Et le plus pervers : aucune erreur n'est signalée. La commande part, se perd en route, et l'espace reste occupé. Vous cherchez une panne là où il n'y a qu'une option non cochée.
Continu ou périodique ?
Le mode continu émet une libération à chaque suppression. C'est immédiat, mais cela place une opération supplémentaire sur le chemin d'écriture, avec une latence variable selon les couches traversées. Sur une pile virtualisée, le comportement est parfois franchement médiocre.
Le mode périodique parcourt l'espace libre à intervalle régulier et libère tout d'un coup. C'est le défaut de la plupart des distributions modernes, et c'est le bon choix dans la quasi-totalité des cas : le coût est concentré sur une fenêtre que vous choisissez, plutôt que dispersé sur chaque écriture.
Un point d'attention : une première passe sur un volume qui n'a jamais été traité peut libérer des centaines de gigaoctets d'un coup et générer une charge d'entrées-sorties importante. Lancez-la en dehors des heures sensibles.
Le contournement par les zéros : à manier avec précaution
Faute de TRIM fonctionnel, la recette la plus partagée consiste à remplir l'espace libre avec un gros fichier de zéros, puis à le supprimer, en espérant que la couche de stockage détectera ces blocs nuls et les désallouera.
Cela fonctionne sur certains stockages. Sur d'autres, c'est exactement le contraire qui se produit : écrire des zéros, c'est écrire des données. Sur un volume à allocation fine géré par le gestionnaire de volumes logiques, vous réallouez massivement les blocs que vous vouliez rendre — et vous pouvez saturer le pool en tentant de le vider.
Avant d'appliquer cette recette, vérifiez le comportement réel de votre couche de stockage. Réparer la chaîne TRIM est presque toujours préférable à la contourner.
Le vrai risque : la saturation du pool
Tout ceci resterait cosmétique si l'espace non rendu n'avait pas une conséquence sérieuse.
Un pool à allocation fine autorise le surprovisionnement : la somme des volumes déclarés peut dépasser la capacité physique. C'est tout l'intérêt, et cela fonctionne tant que les machines n'écrivent pas toutes au maximum.
Mais si l'espace n'est jamais rendu, l'occupation réelle ne fait que croître. Le jour où le pool est plein, les écritures échouent — pas seulement pour une machine, mais pour toutes celles qui partagent le pool. Les systèmes invités basculent en lecture seule dans le meilleur des cas, se corrompent dans le pire.
Un pool à allocation fine doit donc être supervisé sur son occupation réelle, avec une alerte déclenchée largement avant la saturation. C'est la supervision la plus rentable d'une infrastructure virtualisée, et l'une des plus souvent oubliées.
La marche à suivre
Si l'espace ne revient pas, remontez la chaîne dans l'ordre plutôt que d'essayer des recettes : vérifiez que l'invité émet bien des TRIM, que le contrôleur virtuel les transmet, que l'option de libération est active sur le disque, et que le stockage les honore. Le maillon manquant est presque toujours le deuxième — et il ne se signale par aucun message.
Commentaires