Linux : trouver ce qui remplit le disque

Le symptôme est toujours le même : une application refuse d'écrire, une mise à jour échoue, la base de données s'arrête. Et df confirme le diagnostic. Reste à trouver le coupable, méthodiquement.

1. Quel système de fichiers est plein ?

$ df -h
Sys. de fichiers  Taille Utilisé Dispo Uti% Monté sur
/dev/nvme0n1p3      475G    471G  4,0G 100% /
/dev/nvme0n1p2      974M    310M  597M  35% /boot

C'est la colonne « Monté sur » qui dit où chercher. Ici, la racine /.

2. Descendre dans l'arborescence

$ sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -10

• -x reste sur le même système de fichiers (sans cette option, du partirait explorer /proc et les disques montés) ;
• --max-depth=1 donne un total par sous-dossier ;
• sort -h trie en comprenant les unités (K, M, G) ;
• 2>/dev/null masque les « Permission non accordée ». On répète ensuite sur le dossier le plus gros (/var, puis /var/log, etc.) jusqu'à trouver le responsable.

Plus confortable : ncdu

$ sudo dnf install ncdu        # ou apt install ncdu
$ sudo ncdu -x /

Une interface dans le terminal, triée par taille, où l'on navigue avec les flèches. La touche d supprime l'élément sélectionné, avec confirmation.

3. Chercher directement les gros fichiers

sudo find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null

Utile pour repérer l'image ISO oubliée, la sauvegarde SQL de 40 Go laissée dans /tmp, ou le fichier journal d'une application qui n'est jamais renouvelé.

4. Les suspects habituels

Le journal systemd

$ journalctl --disk-usage
$ sudo journalctl --vacuum-size=200M

Pour fixer une limite définitive : SystemMaxUse=200M dans /etc/systemd/journald.conf, puis sudo systemctl restart systemd-journald.

Les caches de paquets

sudo dnf clean all          # Fedora, Rocky, RHEL
sudo apt clean              # Debian, Ubuntu
flatpak uninstall --unused  # runtimes Flatpak qui ne servent plus

Les conteneurs

podman system df            # ou docker system df
podman system prune         # images, conteneurs arrêtés, caches de construction inutilisés

5. Le piège : le fichier supprimé mais toujours ouvert

Vous avez effacé un journal de 20 Go, et df affiche toujours 100 %. C'est normal : tant qu'un processus garde le fichier ouvert, l'espace n'est pas libéré. Le fichier n'a plus de nom, mais il existe encore.

$ sudo lsof +L1
COMMAND   PID  USER  FD  TYPE  SIZE/OFF  NLINK  NODE  NAME
java     1234  app   5w  REG   21474836480  0  …  /var/log/app/app.log (deleted)

La solution est de redémarrer le service concerné (sudo systemctl restart …). Si c'est impossible dans l'immédiat, on peut vider le fichier sans l'arrêter :

sudo truncate -s 0 /proc/1234/fd/5

(avec le PID et le numéro de descripteur FD donnés par lsof).

Et pour la prochaine fois : un journal en cours d'écriture se vide (truncate -s 0 fichier.log), il ne se supprime pas.

6. Plein… mais pas d'octets

Si df -h montre de la place libre et que les écritures échouent quand même avec « No space left on device », regardez les inodes :

$ df -i

À 100 %, ce n'est pas la taille qui manque mais le nombre de fichiers : des millions de petits fichiers (sessions PHP, cache d'une application, file d'attente de mails). Pour trouver le dossier qui en contient le plus :

sudo du -x --inodes --max-depth=1 / 2>/dev/null | sort -n | tail -10