Linux sans magie #36 — Comprendre l’espace disque : df, du et pourquoi ils ne disent pas toujours la même chose

Un serveur annonce qu’un filesystem est presque plein. Vous lancez df -h et voyez 92 % d’utilisation. Puis vous utilisez du dans le répertoire concerné et le total semble beaucoup plus faible.

Quelle commande a raison ?

Très souvent, les deux.

df et du ne répondent pas exactement à la même question. Comprendre cette différence évite une erreur classique : supprimer des fichiers au hasard alors que l’on n’a pas encore identifié ce qui consomme réellement l’espace.

Dans cet article, nous allons apprendre à lire ces deux outils, à comparer leurs résultats et à construire une méthode de diagnostic non destructive.

Contexte et problème

L’espace disque paraît simple tant qu’il en reste beaucoup.

Lorsqu’un filesystem approche de sa capacité maximale, les symptômes peuvent devenir très concrets :

une application ne parvient plus à écrire ;
un log ne peut plus grossir ;
une mise à jour échoue ;
une base de données refuse une opération ;
un service se comporte de manière anormale.

La première réaction est souvent :

df -h

Puis, pour trouver « ce qui prend de la place » :

du -sh <REPERTOIRE>

Ces commandes sont utiles, mais elles ne mesurent pas la même chose.

La documentation GNU Coreutils indique que df rapporte l’espace utilisé et disponible des filesystems montés. du, lui, estime l’espace nécessaire pour représenter les fichiers présents dans une hiérarchie donnée.

La nuance est essentielle : df observe le filesystem ; du parcourt des fichiers et des répertoires.

Concept ou architecture

Ce que mesure df

Avec :

df -h

df interroge les filesystems montés et affiche notamment :

leur taille ;
l’espace utilisé ;
l’espace disponible ;
le pourcentage d’utilisation ;
leur point de montage.

L’option -h rend les tailles plus lisibles.

Vous pouvez aussi cibler un chemin :

df -h <CHEMIN>

Dans ce cas, df indique le filesystem qui contient ce chemin.

C’est une propriété très utile pour le diagnostic : vous n’avez pas besoin de connaître à l’avance le nom du périphérique ou du volume.

Par exemple :

df -h /var

répond à la question :

« Quel filesystem contient /var, et combien d’espace lui reste-t-il ? »

Il ne répond pas directement à :

« Quels fichiers sous /var consomment cet espace ? »

Ce que mesure du

du travaille dans l’autre sens.

Avec :

du -sh <REPERTOIRE>

vous lui demandez d’estimer l’espace occupé par les fichiers accessibles sous cette hiérarchie.

L’option -s demande un total synthétique, tandis que -h utilise un affichage lisible.

Par exemple :

du -x -sh /var/log

répond à une question du type :

« Quelle quantité d’espace est associée aux fichiers que du voit sous /var/log ? »

Pour descendre d’un niveau et identifier les répertoires les plus importants avec GNU du :

du -x -h --max-depth=1 <REPERTOIRE>

L’option -x, ou --one-file-system, évite de traverser vers d’autres filesystems montés sous l’arborescence examinée.

C’est particulièrement utile lorsque l’objectif est d’expliquer l’occupation d’un seul filesystem.

Pourquoi df et du peuvent différer

Une différence entre les deux commandes n’indique pas automatiquement une anomalie.

1. Ils n’observent pas la même source d’information

df s’appuie sur les informations globales du filesystem.

du parcourt la hiérarchie des fichiers.

Il est donc normal que les chiffres ne soient pas strictement identiques.

Le filesystem utilise également de l’espace pour ses propres structures et métadonnées. Tout cet espace n’apparaît pas nécessairement comme la somme simple des fichiers visibles.

2. Un fichier peut être supprimé du répertoire mais encore ouvert

C’est l’une des causes classiques d’un gros écart.

Sous Unix, supprimer un nom de fichier ne signifie pas forcément que l’espace correspondant est immédiatement libéré si un processus possède encore le fichier ouvert.

Imaginez un service qui écrit dans un gros fichier de log. Le fichier est supprimé, mais le processus continue de garder son descripteur ouvert.

Dans cette situation :

du ne retrouve plus le fichier dans l’arborescence ;
le filesystem conserve encore les blocs associés ;
df continue donc de voir cet espace comme utilisé.

La FAQ GNU Coreutils cite explicitement ce cas comme une raison fréquente de divergence entre df et du.

Le diagnostic précis de fichiers supprimés mais encore ouverts sera traité plus tard dans un article de troubleshooting. Pour l’instant, retenez simplement que « supprimé du répertoire » et « espace réellement libéré » ne sont pas toujours simultanés.

3. du peut ne pas avoir accès à toute l’arborescence

Si votre utilisateur ne peut pas parcourir certains répertoires, du peut afficher des erreurs de permission et ne pas comptabiliser tout ce qui s’y trouve.

Dans ce cas, son total est incomplet.

Il ne faut donc pas masquer automatiquement les erreurs avec :

2>/dev/null

pendant un diagnostic.

Une erreur Permission denied est une information : elle indique que votre mesure n’est peut-être pas complète.

L’utilisation de privilèges plus élevés peut parfois être justifiée pour un diagnostic d’administration, mais elle ne doit pas devenir le réflexe initial.

4. Des données peuvent être masquées par un autre montage

Un répertoire peut contenir des fichiers puis devenir le point de montage d’un autre filesystem.

Les anciens fichiers existent toujours sur le filesystem sous-jacent, mais ils ne sont plus directement visibles à travers l’arborescence montée.

Dans ce cas, df peut comptabiliser l’espace utilisé sur le filesystem d’origine alors qu’un du exécuté à travers le montage ne voit plus ces fichiers.

Nous reviendrons sur cette notion lorsque nous étudierons précisément les points de montage.

5. Certains filesystems compliquent encore la comparaison

La documentation GNU signale aussi plusieurs situations où l’estimation de du doit être interprétée avec prudence, notamment avec :

des filesystems utilisant copy-on-write ;
la compression ;
des fichiers partageant certains blocs ;
certains filesystems réseau.

Pour le diagnostic courant, la leçon reste la même : du est un outil d’exploration de la hiérarchie, pas un miroir exact de la comptabilité interne du filesystem.

Prérequis

Les exemples visent un environnement GNU/Linux disposant des GNU Coreutils.

Aucun privilège root n’est nécessaire pour les commandes présentées tant que vous analysez des chemins accessibles à votre utilisateur.

Le lab est uniquement en lecture. Il ne crée, ne supprime et ne modifie aucun fichier.

Mise en pratique

Prenons une méthode simple lorsqu’un filesystem semble trop rempli.

Étape 1 — Identifier le filesystem concerné

Commencez par le chemin qui pose problème.

Par exemple :

df -h /var

Vous obtenez une ligne correspondant au filesystem contenant /var.

Regardez surtout :

Size ;
Used ;
Avail ;
Use% ;
Mounted on.

Ne cherchez pas encore à supprimer quoi que ce soit.

Étape 2 — Mesurer le répertoire de départ

Ensuite :

du -x -sh /var

Si votre utilisateur ne dispose pas de tous les droits nécessaires, lisez les éventuelles erreurs au lieu de les masquer.

Ce résultat donne un premier ordre de grandeur de ce que du peut voir sous /var.

Étape 3 — Descendre d’un niveau

Pour localiser les grands ensembles, utilisez :

du -x -h --max-depth=1 /var

Vous pouvez ensuite appliquer la même logique au répertoire qui ressort comme le plus volumineux :

du -x -h --max-depth=1 /var/<SOUS_REPERTOIRE>

Cette approche est volontairement progressive.

Elle évite de lancer immédiatement une commande très large sur tout le système alors que le problème est peut-être déjà localisé.

Étape 4 — Comparer sans chercher une égalité parfaite

Comparez maintenant :

df -h /var

avec :

du -x -sh /var

Si les valeurs sont proches, la hiérarchie visible explique probablement l’essentiel de l’espace utilisé.

Si df indique beaucoup plus d’espace utilisé que ce que du retrouve, ne concluez pas immédiatement que l’un des outils est faux.

Posez plutôt ces questions :

du a-t-il rencontré des erreurs de permission ?
l’arborescence contient-elle d’autres filesystems montés ?
un processus pourrait-il conserver un gros fichier supprimé ouvert ?
le type de filesystem utilise-t-il des mécanismes qui rendent l’estimation moins directe ?

Résultat attendu

À la fin de cette procédure, vous devez être capable d’identifier :

le filesystem réellement concerné ;
son niveau global d’occupation ;
les principaux répertoires visibles qui consomment de l’espace ;
l’existence éventuelle d’un écart qui nécessite un diagnostic supplémentaire.

Le résultat attendu n’est pas nécessairement une égalité entre df et du.

Le résultat attendu est de savoir expliquer ce que chaque chiffre représente.

Vérification

Une vérification simple consiste à exécuter :

df -h <CHEMIN>

puis :

du -x -h --max-depth=1 <CHEMIN>

Vérifiez ensuite trois points :

df cible bien le filesystem contenant le chemin ;
du termine sans erreur non expliquée ;
vous savez si l’écart observé est faible ou suffisamment important pour poursuivre le diagnostic.

Si du affiche des erreurs d’accès, considérez sa mesure comme partielle tant que ces zones n’ont pas été prises en compte.

Bonnes pratiques

Commencez par df avant du.

df vous indique quel filesystem manque réellement d’espace. Cela évite de chercher dans une arborescence située sur un autre filesystem.

Ensuite, utilisez du de manière ciblée et progressive.

Préférez :

du -x -h --max-depth=1 <REPERTOIRE>

à une exploration aveugle de tout /.

Ne supprimez jamais un fichier uniquement parce qu’il est volumineux. Un gros fichier peut être nécessaire à une application, à une base de données ou à un mécanisme de journalisation.

Identifiez d’abord son rôle, son propriétaire et le processus qui l’utilise.

Enfin, gardez les erreurs visibles pendant le diagnostic. Masquer stderr peut rendre l’affichage plus propre, mais peut aussi cacher la raison pour laquelle du sous-estime l’espace réellement accessible.

Sécurité

Les commandes présentées sont des commandes de lecture.

Le principal risque apparaît lorsque le diagnostic conduit trop rapidement à une suppression.

Évitez les enchaînements du type « trouver les plus gros fichiers puis les supprimer » sans analyse intermédiaire.

Sur un serveur, l’espace disque peut appartenir à :

des logs gérés par un mécanisme de rotation ;
des fichiers de données d’une application ;
des fichiers temporaires encore utilisés ;
des sauvegardes ;
des artefacts nécessaires à un service.

Le diagnostic doit donc précéder toute action destructive.

Coûts

Aucun service cloud ni ressource facturable n’est nécessaire pour cet article.

Les commandes peuvent toutefois générer des lectures importantes sur une grande arborescence. Sur un système très chargé, un du récursif peut consommer du temps CPU et provoquer des opérations d’entrée/sortie.

Il est donc préférable de cibler progressivement le périmètre à analyser.

Limites et points de vigilance

Cet article ne cherche pas encore à expliquer en détail :

les partitions ;
les périphériques bloc ;
les points de montage ;
lsblk ;
findmnt ;
les inodes ;
LVM ;
les filesystems eux-mêmes.

Ces sujets appartiennent aux prochaines étapes du bloc stockage.

Nous n’utilisons pas non plus ici un outil comme lsof pour identifier les fichiers supprimés mais encore ouverts. Le mécanisme est présenté parce qu’il explique un écart fréquent entre df et du, mais son diagnostic détaillé mérite une procédure séparée.

Enfin, les exemples utilisent des options GNU Coreutils. Sur un autre environnement Unix, certaines options peuvent différer.

Rollback ou nettoyage

Aucun rollback n’est nécessaire.

Toutes les commandes de cet article consultent l’état du système sans le modifier.

Si votre diagnostic montre qu’une action de nettoyage est nécessaire, traitez cette action comme une étape séparée : identifiez d’abord la ressource, vérifiez son rôle, puis définissez une méthode de suppression ou de rotation adaptée avec une vérification après intervention.

Références officielles

GNU Coreutils — File space usage — GNU Project
GNU Coreutils — df invocation — GNU Project
GNU Coreutils — du invocation — GNU Project
GNU Core Utilities FAQ — df and du report different information — GNU Project

Conclusion

df et du ne sont pas deux façons concurrentes de mesurer exactement la même chose.

df décrit l’occupation globale d’un filesystem. du explore une hiérarchie de fichiers et estime l’espace correspondant à ce qu’il peut voir.

La bonne méthode consiste donc à utiliser df pour identifier le filesystem en difficulté, puis du pour explorer progressivement la hiérarchie visible.

Dans le prochain article, nous poserons le vocabulaire nécessaire pour aller plus loin : disque, partition, filesystem et point de montage.