No space left on device donne envie d’effacer « ce qui a l’air gros ». C’est comme ça qu’on vide le mauvais mount, qu’on casse un journal ouvert, ou qu’on ignore des inodes épuisés alors que df -h ment encore. L’entretien teste l’ordre, pas la syntaxe de du.
1. Quel système de fichiers, pas quel dossier.
df -h
df -ihLa colonne Mounted on dit si c’est /, /var, /tmp ou un volume Docker. df -ih écarte tout de suite le cas « plus d’inodes, encore des blocs ». Tant que vous n’avez pas le mount à 100 %, chercher dans /home est du théâtre.
2. Où ça pèse, sans traverser les autres disques.
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail-x reste sur un seul FS. En une passe vous savez si c’est /var/log, /var/lib/docker, un core dump ou un build. Puis vous zoomez d’un niveau, jamais « du / » sans plafond.
3. Les journaux et le journald.
sudo journalctl --disk-usage
sudo ls -lhS /var/log | headUn .log de 40 Go après un weekend de debug est banal. On tronque (truncate -s 0) plutôt que rm si le démon tient encore le descripteur : sinon l’espace ne revient pas.
4. L’espace fantôme.
du ne voit plus un fichier unlinké ; df compte encore les blocs tant qu’un processus l’a ouvert.
sudo lsof +L1La sortie « deleted » + un Java ou un conteneur : on redémarre ce processus, on ne continue pas à supprimer ailleurs.
Vous séparez mesure, localisation, libération sans casser le descripteur. Vous nommez inodes et fichiers orphelins. Vous ne proposez pas docker system prune --volumes en première phrase sur une prod : sur une machine de build c’est parfois le bon deuxième geste, en production c’est un risque de volume anonyme.
On privilégie ce qui est regénérable : journaux, caches de paquets, artefacts de CI, images mortes. On ne touche pas à /var/lib/postgresql, aux volumes nommés, ni à un lost+found par panique. Un rm dans /var/lib/docker à la main est pire que le prune documenté. Après libération, on revérifie df -h et df -ih : si les blocs n’ont pas bougé, on revient à lsof, on n’invente pas un troisième coup de balai.
La relance « On a tout effacé, df n’a pas bougé » doit tomber sur lsof et le redémarrage du détenteur, pas sur un second rm -rf.
La relance « Root a encore 5 % et l’appli échoue » : réserve root d’ext4, ou le process n’est pas root. Ce n’est plus « disque plein » au sens df grand public, c’est le même protocole de mesure.
La démarche détaillée, commandes dans l’ordre, est dans disque plein sous Linux : diagnostiquer en 5 commandes.