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

Espace par filesystem

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

df -h /var
df -h /tmp

Espace en pourcentage pour un script

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

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

• 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

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

Les 10 répertoires les plus volumineux

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

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

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

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

Trouver les gros fichiers — find

Fichiers de plus de 100 Mo

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

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

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

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

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

À 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

Prochaines étapes

Contrôler capacité et quotas Quotas disque, ncdu, stratégies de gestion d'espace avancées

Vérifier la charge système Load average, CPU, mémoire — diagnostic de performance global

Gérer le stockage logique (LVM) Étendre un volume logique quand l'espace manque

Journaux système avec journalctl Filtrer et limiter les journaux pour contrôler l'espace

×

📖 Voir la documentation →