Contrôler l'espace disque et les inodes sous Linux

df -h montre l'espace utilisé par filesystem, df -i montre les inodes, quand l'un des deux atteint 100 %, Linux retourne No space left on device même s'il reste de la place sur l'autre plan. Le diagnostic commence toujours par ces deux commandes.

Ce que vous allez apprendre

• Distinguer saturation d'espace et saturation d'inodes
• Identifier les répertoires et fichiers les plus volumineux avec du
• Détecter les fichiers supprimés encore ouverts avec lsof
• Diagnostiquer un épuisement des inodes (df -i)
• Libérer de l'espace de façon sûre en production
• Comprendre le rôle des blocs réservés sur ext4

Dans quel contexte ?

Le contrôle de l'espace disque revient en permanence en administration :

• Un service refuse de démarrer ou une application plante avec No space left on device, le réflexe est de vérifier df -h
• Après une rotation de logs ratée, /var/log a grossi insidieusement et sature la partition
• Un conteneur ou un build CI écrit des fichiers temporaires qui ne sont jamais nettoyés
• df montre de la place disponible mais la création de fichiers échoue, c'est un problème d'inodes
• Vous devez justifier un redimensionnement de partition ou de volume logique auprès de l'équipe infra

LFCS / RHCSA

La gestion de l'espace disque est un objectif explicite du domaine Commandes essentielles de la LFCS (managing disk usage) et fait partie des compétences attendues en stockage pour la RHCSA. Vous devez savoir utiliser df, du et find -size sans hésiter.

Vérifier l'espace disponible, df

df (disk free) interroge chaque filesystem monté et rapporte l'occupation vue par le noyau. C'est toujours la première commande à lancer, parce qu'elle raisonne par point de montage : un serveur peut avoir / à 40 % et /var à 100 %, et seul df le montre. L'option -h (human readable) convertit les blocs en unités lisibles ; sans elle, les tailles s'affichent en blocs de 1 kilooctet.

Espace par filesystem

Sans argument, df liste tous les filesystems montés. Les lignes tmpfs correspondent à des systèmes de fichiers en mémoire vive, qui disparaissent au redémarrage et ne consomment aucun espace disque.

df -h

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv  914G  616G  260G  71% /
tmpfs                              24G   1.2M   24G   1% /run
/dev/sda2                          2.0G  130M  1.7G   8% /boot

Colonne	Signification
Size	Taille totale du filesystem
Used	Espace utilisé
Avail	Espace réellement disponible (exclut les blocs réservés)
Use%	Pourcentage d'utilisation
Mounted on	Point de montage

Glissez pour voir

Surveiller les bons points de montage

Sur un serveur, vérifiez toujours /, /var, /tmp et /home séparément s'ils sont sur des partitions distinctes. Une saturation de /var n'apparaît pas si vous ne regardez que /.

Filtrer sur un point de montage

En passant un chemin, df n'affiche que le filesystem qui contient ce chemin. Utile pour lever un doute : si df -h /var renvoie la même ligne que df -h /, c'est que /var n'est pas sur une partition séparée.

df -h /var
df -h /tmp

Espace en pourcentage pour un script

Pour une alerte automatisée, on extrait la seule valeur qui intéresse. NR==2 saute la ligne d'en-tête et $5 désigne la colonne Use%.

df -h / | awk 'NR==2 {print $5}'

71%

Utilisable dans un script d'alerte :

usage=$(df -h / | awk 'NR==2 {gsub(/%/,""); print $5}')
if [[ "$usage" -gt 90 ]]; then
    echo "ALERTE : / est à ${usage}%"
fi

Vérifier les inodes, df -i

Un filesystem gère deux ressources indépendantes : l'espace de données, exprimé en octets, et les inodes, qui comptent les fichiers. L'une peut être épuisée alors que l'autre est presque vide, et le message d'erreur retourné par le noyau est identique dans les deux cas. C'est pourquoi le diagnostic complet réclame df -h puis df -i.

Pourquoi les inodes comptent

Chaque fichier (ou répertoire) occupe un inode, une structure de métadonnées qui stocke les permissions, les timestamps et les pointeurs vers les blocs de données. Le nombre total d'inodes est fixé à la création du filesystem (sur ext4). Quand tous les inodes sont consommés, impossible de créer un nouveau fichier même si l'espace disque n'est pas plein.

df -i /

Filesystem                          Inodes    IUsed    IFree IUse% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv 60850176 32625792 28224384   54% /

Colonne	Signification
Inodes	Nombre total d'inodes du filesystem
IUsed	Inodes utilisées
IFree	Inodes disponibles
IUse%	Pourcentage d'utilisation des inodes

Glissez pour voir

Quand soupçonner un problème d'inodes

Trois signaux doivent orienter le diagnostic vers les inodes plutôt que vers l'espace. Le premier est décisif : une écriture qui échoue alors que df -h affiche des gigaoctets libres ne peut pas s'expliquer autrement.

• df -h montre de la place disponible mais touch /tmp/test retourne No space left on device
• Un répertoire contient des millions de petits fichiers (cache, sessions PHP, mails en queue)
• IUse% dépasse 90 % sur df -i

Trouver les répertoires avec le plus de fichiers

Il n'existe pas d'équivalent de du pour compter les inodes : il faut dénombrer les fichiers répertoire par répertoire. La commande ci-dessous parcourt tout le filesystem racine et classe les répertoires par nombre de fichiers directs. Elle est longue à s'exécuter sur un disque volumineux, -xdev limitant au moins le parcours au filesystem courant.

find / -xdev -type d -exec sh -c 'echo "$(find "$1" -maxdepth 1 -type f | wc -l) $1"' _ {} \; 2>/dev/null | sort -rn | head -10

xfs et les inodes

Sur XFS, les inodes sont alloués dynamiquement, le problème d'épuisement est beaucoup plus rare qu'avec ext4. Si vous rencontrez un problème d'inodes sur ext4, la migration vers XFS est parfois la bonne solution à long terme.

Identifier ce qui consomme l'espace, du

Là où df interroge le noyau, du (disk usage) parcourt réellement l'arborescence et additionne la taille des fichiers. Cette différence de méthode explique deux comportements : du est beaucoup plus lent, et il peut totaliser nettement moins que df quand des fichiers supprimés restent ouverts. Lancez-le avec sudo pour ne pas manquer les répertoires que votre compte ne peut pas lire, et redirigez les erreurs vers /dev/null pour garder une sortie exploitable.

Les 10 répertoires les plus volumineux

Le tri sort -rh classe par taille décroissante en comprenant les suffixes G, M et K produits par -h. La première ligne est toujours le total du point de départ, ici /.

sudo du -ahx / 2>/dev/null | sort -rh | head -10

188G    /
166G    /home
87G     /home/bob/Projets
35G     /home/bob/.cache
29G     /home/bob/Projets/lab

Option	Rôle
-a	Affiche aussi les fichiers (pas seulement les répertoires)
-h	Tailles lisibles (G, M, K)
-x	Reste sur le même filesystem (ne traverse pas les montages)

Glissez pour voir

Cibler un répertoire spécifique

Une fois le coupable localisé au niveau global, on descend d'un cran. L'option -s (summarize) n'affiche qu'un total par argument au lieu de détailler toute la descendance, ce qui rend la sortie immédiatement lisible.

sudo du -sh /var/log/*  2>/dev/null | sort -rh | head -5

633M    /var/log/journal
13M     /var/log/pods
13M     /var/log/crowdsec_api.log
2.5M    /var/log/harbor
1.5M    /var/log/libvirt

Résumé par répertoire de premier niveau

C'est la commande à lancer en premier quand vous découvrez une machine : elle tient en une dizaine de lignes et désigne tout de suite la branche à explorer.

sudo du -sh /* 2>/dev/null | sort -rh

Donne une vue immédiate de la répartition globale.

Trouver les gros fichiers, find

du désigne des répertoires, find désigne des fichiers. La bascule est utile quand un seul fichier explique la saturation : une image disque oubliée, un dump de base de données, un log jamais tourné. Trois critères suffisent à couvrir la plupart des recherches : la taille (-size), la date de modification (-mtime) et la date de dernier accès (-atime).

Fichiers de plus de 100 Mo

-xdev empêche find de descendre dans les autres filesystems montés, ce qui évite de parcourir un partage réseau ou un disque de sauvegarde. Le tri porte sur la cinquième colonne de ls -lh, celle de la taille.

sudo find / -xdev -type f -size +100M -exec ls -lh {} \; 2>/dev/null | sort -k5 -rh | head -10

Fichiers modifiés récemment et volumineux

Croiser taille et fraîcheur répond à une autre question : qu'est-ce qui grossit en ce moment. Le signe de -mtime inverse le sens du critère, -7 désignant les 7 derniers jours et +7 ce qui est plus ancien.

sudo find /var -type f -size +10M -mtime -7 -exec ls -lh {} \; 2>/dev/null

Cible les fichiers de plus de 10 Mo modifiés dans les 7 derniers jours sous /var, utile pour trouver un log qui grossit vite.

Anciens fichiers temporaires

-atime s'appuie sur la date de dernier accès, plus pertinente que la date de modification pour repérer ce qui n'est plus utilisé. Cette information n'est fiable que si le filesystem n'est pas monté avec l'option noatime, courante sur les serveurs pour économiser des écritures.

find /tmp -type f -atime +30 -exec ls -lh {} \; 2>/dev/null

Fichiers dans /tmp non accédés depuis plus de 30 jours, candidats au nettoyage.

Détecter les fichiers supprimés encore ouverts

Un fichier supprimé avec rm mais encore ouvert par un processus continue d'occuper l'espace disque. C'est une cause fréquente d'espace « fantôme » : du ne voit rien mais df montre le filesystem plein.

sudo lsof +L1

COMMAND    PID   USER  FD   TYPE DEVICE SIZE/OFF NLINK  NODE NAME
nginx     1234   www   4w   REG  253,0  2.1G     0   131074 /var/log/nginx/access.log (deleted)

L'espace ne sera libéré que quand le processus qui tient le fichier ouvert sera redémarré :

sudo systemctl restart nginx

Après le redémarrage, df -h reflète immédiatement l'espace récupéré.

Ne pas tuer un processus critique

Avant de redémarrer un service pour libérer l'espace d'un fichier supprimé, vérifiez l'impact sur la production. Préférez systemctl restart à kill -9.

Comprendre les blocs réservés (ext4)

Sur ext4, 5 % de l'espace est réservé par défaut à l'utilisateur root. Cela explique la différence entre Size, Used et Avail dans df :

sudo tune2fs -l /dev/mapper/ubuntu--vg-ubuntu--lv | grep -i reserved

Reserved block count:     10002749
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

Cet espace réservé permet à root de continuer à écrire (logs système, processus critiques) même quand un utilisateur normal voit No space left.

Réduire les blocs réservés

Sur un volume de données pur (pas /), vous pouvez réduire le pourcentage réservé :

sudo tune2fs -m 1 /dev/mapper/data-lv

Change la réserve de 5 % à 1 %. Ne faites pas ça sur /, les processus système ont besoin de cette marge.

Vérifier l'espace des journaux systemd

Les journaux systemd peuvent occuper plusieurs centaines de Mo :

journalctl --disk-usage

Archived and active journals take up 632.5M in the file system.

Pour limiter à 200 Mo :

sudo journalctl --vacuum-size=200M

Pour ne garder que les 7 derniers jours :

sudo journalctl --vacuum-time=7d

Rendez la limite persistante dans /etc/systemd/journald.conf :

[Journal]
SystemMaxUse=200M

Puis rechargez :

sudo systemctl restart systemd-journald

Procédure de nettoyage en production

Sur un serveur en service, l'ordre des opérations compte autant que les commandes. On diagnostique avant de supprimer, on commence par les candidats réversibles (caches, journaux anciens, paquets orphelins) et on ne touche aux données applicatives qu'en dernier recours. La suppression sous Linux étant irréversible, chaque étape ci-dessous se limite à des cibles que le système sait régénérer.

1. Diagnostiquer, espace ou inodes ?

   df -h /
   df -i /

2. Localiser, quels répertoires consomment le plus ?

   sudo du -sh /var/* /tmp/* /home/* 2>/dev/null | sort -rh | head -10

3. Vérifier les fichiers supprimés ouverts

   sudo lsof +L1

4. Nettoyer les candidats sûrs

   # Anciens journaux
   sudo journalctl --vacuum-time=7d
   
   # Cache APT
   sudo apt clean            # Debian/Ubuntu
   sudo dnf clean all        # RHEL/Fedora
   
   # Fichiers temporaires anciens
   sudo find /tmp -type f -atime +30 -delete
   
   # Anciens noyaux (Debian/Ubuntu)
   sudo apt autoremove --purge

5. Vérifier le résultat

   df -h /

Ne jamais supprimer /var/log à l'aveugle

Supprimer les fichiers de log d'un service en cours d'exécution peut provoquer un dysfonctionnement. Préférez truncate -s 0 /var/log/fichier.log pour vider un fichier sans le supprimer, ou redémarrez le service après la suppression.

Dépannage

Les deux premières lignes du tableau couvrent les situations les plus déroutantes, celles où les commandes semblent se contredire. Retenez la règle de lecture : quand df et du ne s'accordent pas, la différence est presque toujours occupée par des fichiers supprimés encore ouverts.

Symptôme	Cause probable	Solution
No space left on device mais df -h montre de la place	Inodes épuisés	df -i pour confirmer, supprimer les petits fichiers inutiles
df plein mais du / montre beaucoup moins	Fichiers supprimés encore ouverts	lsof +L1 puis redémarrer le service concerné
/var remplit très vite	Logs non rotatés ou journal systemd sans limite	Configurer logrotate et SystemMaxUse dans journald.conf
Avail plus petit que Size - Used	Blocs réservés root (5 % par défaut sur ext4)	Normal, réduire avec tune2fs -m si c'est un volume de données
Script d'alerte ne détecte pas la saturation	Mauvais point de montage vérifié	Vérifier /var, /tmp, /home séparément
Partition pleine après build Docker	Images et layers non nettoyés	docker system prune ou podman system prune

Glissez pour voir

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Deux causes de No space left on device : espace plein (df -h) ou inodes épuisés (df -i), vérifiez toujours les deux
• du -sh identifie les répertoires volumineux ; find -size cible les gros fichiers individuels
• Les fichiers supprimés encore ouverts (lsof +L1) sont la cause la plus fréquente d'espace fantôme
• Les blocs réservés root (5 % sur ext4) expliquent la différence entre espace total et espace disponible
• Les journaux systemd peuvent être limités avec SystemMaxUse dans /etc/systemd/journald.conf
• Sur XFS, les inodes sont dynamiques, le risque d'épuisement est quasi inexistant

Pour aller plus loin

• Contrôler capacité et quotas : Quotas disque, ncdu, stratégies de gestion d'espace avancées.
• Gérer le stockage logique (LVM) : Étendre un volume logique quand l'espace manque.

×

📖 Voir la documentation →