Linux : df affiche 100 % mais du ne trouve rien — diagnostiquer sans supprimer au hasard
Un serveur qui annonce « disque plein » alors que du ne retrouve pas les gigaoctets manquants, c’est le genre de situation qui pousse vite à supprimer des fichiers au hasard. Mauvais réflexe : l’écart entre df et du est justement un indice utile.
Les deux commandes ne regardent pas la même chose. df interroge l’état global du système de fichiers ; du additionne l’espace occupé par les fichiers qu’il peut encore parcourir dans l’arborescence. Un gros écart peut donc venir d’un fichier supprimé mais toujours ouvert, d’un manque d’inodes, de blocs réservés ou simplement d’un mauvais périmètre de mesure.
Commencer par mesurer le bon système de fichiers
Avant toute action, il faut identifier le point de montage réellement concerné. Ces commandes sont en lecture seule :
df -hT
findmnt -T /var
sudo du -xhd1 /var 2>/dev/null | sort -hdf -hTaffiche l’occupation, le type de système de fichiers et le point de montage.findmnt -T /varindique précisément quel système de fichiers contient/var.du -xreste sur ce même système de fichiers. Sans cette option, un montage présent sous/varpeut fausser la comparaison.
Il faut aussi utiliser les droits adaptés. Un du lancé sans privilèges peut ignorer des répertoires auxquels l’utilisateur n’a pas accès. Les erreurs redirigées vers /dev/null rendent l’affichage plus lisible, mais on peut retirer cette redirection si l’on cherche justement un problème de permissions.
Cause numéro 1 : un fichier supprimé est encore ouvert
Sous Linux, supprimer le nom d’un fichier ne libère pas forcément ses blocs immédiatement. Si un processus conserve un descripteur ouvert, le fichier reste présent en coulisses jusqu’à la fermeture du dernier descripteur. du ne le voit plus dans l’arborescence, mais df compte toujours son espace.
La commande suivante cherche les fichiers ouverts dont le nombre de liens est inférieur à 1, donc les fichiers supprimés mais encore utilisés :
sudo lsof +L1Pour limiter la recherche à un système de fichiers précis :
sudo lsof +aL1 /varRegardez surtout les colonnes COMMAND, PID, SIZE/OFF et NAME. Un journal de plusieurs dizaines de gigaoctets marqué (deleted) explique souvent l’écart.
La bonne correction n’est pas de bricoler directement dans /proc/<PID>/fd. Il faut identifier le service, comprendre pourquoi son fichier a été supprimé sans être rouvert, puis programmer une action contrôlée :
systemctl status <service>
journalctl -u <service> --since "30 min ago"
sudo systemctl restart <service>Le redémarrage ferme les descripteurs et rend normalement l’espace. Mais il peut interrompre le service ou faire perdre un état non enregistré : on vérifie donc l’impact avant de le lancer. Ensuite, il faut corriger la cause — rotation de journaux mal configurée, conteneur bavard, application qui ne rouvre pas ses logs après rotation — sinon le problème reviendra.
Cause numéro 2 : il reste des gigaoctets, mais plus d’inodes
Chaque fichier consomme un inode. Une accumulation de millions de petits fichiers peut épuiser les inodes alors que le volume dispose encore d’espace en octets. Le symptôme ressemble à un disque plein : créations impossibles, erreurs d’écriture, services qui démarrent mal.
df -ihSi la colonne IUse% atteint 100 %, il faut localiser l’explosion de fichiers. Cette commande compte les fichiers par répertoire sur /var :
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
| sort | uniq -c | sort -n | tail -30Attention : sur un volume très rempli, ce parcours peut solliciter fortement les entrées-sorties. Commencez par un sous-répertoire suspect et lancez-le en période calme si nécessaire. Ne supprimez pas un dossier uniquement parce qu’il contient beaucoup de fichiers : il peut s’agir d’une file de messages, d’un cache applicatif ou de données encore nécessaires.
Cause numéro 3 : les blocs réservés d’ext4
Les systèmes de fichiers ext2, ext3 et ext4 peuvent réserver une partie des blocs aux processus privilégiés. Cette réserve permet notamment aux services essentiels de continuer à écrire quand les utilisateurs ordinaires voient le volume comme plein, et elle aide à limiter la fragmentation.
Vérifiez d’abord le type et le périphérique :
findmnt -no SOURCE,FSTYPE,TARGET /varUniquement si le système de fichiers est de type ext2, ext3 ou ext4, on peut lire ses paramètres :
sudo tune2fs -l /dev/DEVICE \
| grep -E 'Block count|Reserved block count|Block size'tune2fs -m permet de modifier le pourcentage réservé, mais c’est une modification du système de fichiers, pas une commande de diagnostic. La documentation indique une valeur par défaut habituelle de 5 %. Sur un très gros volume dédié uniquement aux données, ce réglage peut être réévalué. Sur la partition racine, réduire la marge sans comprendre les conséquences peut transformer une alerte gérable en panne complète.
Le tableau de diagnostic rapide
| Constat | Cause probable | Prochaine vérification |
|---|---|---|
df -h est plein, du trouve beaucoup moins | Fichier supprimé encore ouvert | sudo lsof +L1 |
| Il reste des octets, mais les écritures échouent | Inodes épuisés | df -ih |
| Un utilisateur voit le volume plein, mais root peut encore écrire | Blocs réservés sur ext* | findmnt, puis tune2fs -l |
du varie selon le chemin ou l’utilisateur | Montage imbriqué ou permissions | findmnt -R, du -x et test avec les droits adaptés |
Éviter que le disque se remplisse à nouveau
Une fois l’urgence réglée, le vrai travail commence : empêcher la récidive. Quelques contrôles simples font une grosse différence :
- surveiller séparément l’occupation des blocs et celle des inodes ;
- configurer et tester la rotation des journaux ;
- plafonner les journaux de conteneurs et ceux du journal systemd selon le contexte ;
- mettre des alertes avant 100 %, avec assez de marge pour intervenir ;
- documenter les répertoires temporaires, caches et files d’attente propres aux applications.
Le point important : un écart entre df et du n’est pas une invitation à lancer un grand nettoyage. C’est un signal. On mesure le bon point de montage, on cherche les fichiers ouverts supprimés, on contrôle les inodes, puis seulement on examine les réserves du système de fichiers. Cette méthode prend quelques minutes de plus, mais elle évite beaucoup de dégâts.