Le service refuse d'écrire, le système annonce un disque plein. Vous regardez : 60 % d'occupation. Vous supprimez le plus gros journal que vous trouvez, et rien ne bouge.
Quatre causes couvrent la quasi-totalité de ces situations. Prises dans l'ordre, elles se diagnostiquent en quelques minutes.
1. Le fichier supprimé qui occupe toujours l'espace
C'est de loin la cause la plus fréquente, et la plus contre-intuitive.
Sous Linux, supprimer un fichier ne fait que retirer son entrée du répertoire. Les blocs ne sont libérés que lorsque le dernier descripteur ouvert sur ce fichier est fermé.
Le scénario est classique : un service écrit dans un journal qui a grossi démesurément. Vous le supprimez pour faire de la place. Le service, lui, garde son descripteur ouvert — et continue joyeusement d'écrire dans un fichier désormais invisible, qui continue de grossir.
La signature est nette : l'outil de mesure de l'occupation annonce un disque plein, tandis que l'analyse des répertoires ne trouve pas de quoi le justifier. L'écart correspond exactement à ce qui a été supprimé sans être fermé.
La correction : identifier les processus tenant des fichiers supprimés, puis les redémarrer ou leur demander de rouvrir leurs journaux. Et pour l'avenir, mettre en place une rotation des journaux plutôt que de les supprimer à la main — la rotation prévient le service, la suppression non.
2. Les inodes épuisés
Ici, le disque n'est réellement pas plein — c'est autre chose qui l'est.
Chaque fichier consomme un inode, qui stocke ses métadonnées. Leur nombre est fixé à la création du système de fichiers et ne peut pas être augmenté ensuite.
Un système qui accumule des millions de petits fichiers — caches applicatifs, sessions web, courriels, files d'attente — peut épuiser cette table alors que l'espace disque reste largement disponible.
Le message d'erreur parle pourtant d'espace insuffisant, ce qui envoie sur une fausse piste. Il suffit de consulter l'occupation des inodes pour trancher : si elle est à 100 % alors que l'espace ne l'est pas, vous avez votre réponse.
Le traitement est de supprimer les petits fichiers inutiles — souvent un répertoire de cache oublié. Si le problème est structurel, il faut recréer le système de fichiers avec une densité d'inodes supérieure, ou choisir un système de fichiers qui les alloue dynamiquement.
3. Les blocs réservés à root
Par défaut, ext4 réserve 5 % des blocs à l'utilisateur root. Un utilisateur ordinaire voit donc son disque plein alors qu'il reste de la place — place qu'il n'a pas le droit d'utiliser.
Cette réserve a deux justifications valables : permettre à un service système d'écrire encore quand le disque se remplit, et limiter la fragmentation en évitant le remplissage complet.
Sur une partition système, elle est utile. Sur un volume de données de plusieurs téraoctets, 5 % représentent des dizaines de gigaoctets immobilisés sans bénéfice réel.
Cette réserve peut être ajustée à chaud, sans démonter le volume. Réduisez-la à 1 % ou à zéro sur un volume purement de données ; laissez-la sur la partition racine.
4. Le montage qui masque des fichiers
Cas plus rare, mais parfaitement déroutant quand il survient.
Vous écrivez des données dans un répertoire. Plus tard, vous montez un disque sur ce même répertoire. Les fichiers d'origine deviennent invisibles — le montage les recouvre — mais ils occupent toujours l'espace du volume sous-jacent.
Le scénario typique : un répertoire de données rempli pendant des semaines avant que le disque prévu pour lui ne soit enfin monté. Des dizaines de gigaoctets disparaissent de la vue tout en restant comptabilisés.
Pour les retrouver, il faut monter la racine du volume à un autre endroit et inspecter le chemin masqué. Les fichiers sont là, intacts, simplement recouverts.
Les faux écarts
Deux mécanismes produisent des différences légitimes entre la taille annoncée des fichiers et l'espace réellement consommé.
Les fichiers creux déclarent une taille importante mais n'occupent que les zones effectivement écrites : c'est courant pour les images disque de machines virtuelles. Ils occupent moins que ce qu'ils annoncent.
Les instantanés font l'inverse : ils retiennent des blocs qui n'apparaissent dans aucun fichier courant. L'espace est consommé, aucun fichier visible ne l'explique. Sur un système gérant les instantanés, c'est toujours la première chose à vérifier.
L'ordre de diagnostic
- Comparer l'occupation annoncée par le système et la somme réelle des répertoires. Un écart oriente immédiatement vers les fichiers supprimés ouverts ou les instantanés.
- Vérifier les inodes : c'est instantané et cela élimine ou confirme la deuxième cause.
- Chercher les fichiers supprimés encore ouverts, et redémarrer les processus concernés.
- Vérifier les montages et inspecter les répertoires susceptibles d'avoir été remplis avant montage.
Et lancez l'analyse avec les privilèges nécessaires : un outil qui n'a pas le droit de lire un répertoire l'ignore silencieusement, et vous cherchez alors un espace manquant qui était simplement hors de portée de la mesure.
Commentaires