Où est passé l’espace disque : analyse et nettoyage

« Disque presque plein » finit par arriver à tout utilisateur d’Ubuntu. Le plus agaçant, c’est que df vous dit que c’est plein sans dire ce qui l’a rempli. Voici l’ordre reproductible : d’abord localiser, ensuite nettoyer.

Étape 1 : à quel point est-ce vraiment plein

df -h

Regardez la colonne Use%, surtout pour / (le système de fichiers racine) et pour /home s’il s’agit d’une partition séparée.

L’équivalent graphique est la barre d’utilisation dans Disques après avoir sélectionné une partition, ou la barre de capacité en bas de la barre latérale du gestionnaire de fichiers.

Étape 2 : trouver les gros répertoires

du sait le calculer, mais on finit par deviner niveau par niveau :

# Size of each subdirectory here, largest first
du -h --max-depth=1 . | sort -hr | head

L’analyseur d’utilisation du disque (baobab) analyse toute l’arborescence d’un coup et se lit beaucoup plus facilement :

sudo apt install baobab
baobab /home/$USER

Il commence à analyser le chemin que vous lui indiquez et, une fois terminé, vous obtenez ceci :

Comment le lire :

• La liste de gauche est triée par taille ; dépliez les lignes flèche par flèche pour obtenir les chemins exacts, ce qui est plus efficace que de cliquer sur les anneaux
• Treemap Chart en bas à droite transforme les proportions en surfaces, le plus gros bloc saute donc aux yeux immédiatement
• Cette capture provient d’une VM fraîchement installée où snap représente à lui seul 87 % — ce n’est pas un bug : chaque application Snap conserve plusieurs révisions

Étape 3 : nettoyer les suspects habituels

Anciennes révisions Snap

Snap conserve les dernières révisions pour permettre un retour arrière, et chacune est une copie complète du programme. C’est ce qui explique les 87 % ci-dessus.

# Keep 2 revisions instead of the default 3
sudo snap set system refresh.retain=2
 
# Remove every disabled revision
sudo snap list --all | awk '/disabled/{print $1, $3}' | while read name rev; do
  sudo snap remove "$name" --revision="$rev"
done

Paquets téléchargés

# Empty /var/cache/apt/archives
sudo apt clean
 
# Drop dependencies nothing needs any more
sudo apt autoremove --purge

Journal systemd

Les journaux de journalctl peuvent atteindre plusieurs Go :

# Keep at most 200 MB
sudo journalctl --vacuum-size=200M
 
# Or keep only 7 days
sudo journalctl --vacuum-time=7d

Caches utilisateur

Les navigateurs, les vignettes et les caches d’applications vivent tous dans ~/.cache :

du -h --max-depth=1 ~/.cache | sort -hr | head

Réfléchissez avant de supprimer : les caches de navigateur se reconstituent à la demande et vous gardent généralement connecté, tandis que ~/.cache/thumbnails peut toujours être supprimé sans risque.

Étape 4 : quand le nettoyage ne suffit pas

Le nettoyage fait gagner du temps ; gagner réellement de l’espace suppose d’agrandir ou de déplacer :

• Machines virtuelles : agrandissez le disque virtuel dans les paramètres de la VM, puis étendez la partition (growpart et resize2fs)
• Machines physiques : ajoutez un disque, formatez-le et montez-le — voir Disques, montage et fstab
• Déplacer des données : déplacez les gros répertoires comme ~/Downloads ou la racine de données Docker vers le nouveau disque et montez-les via fstab

FAQ

df dit plein mais du totalise beaucoup moins

Le cas classique : un fichier a été supprimé mais un processus le garde encore ouvert, l’espace n’est donc libéré qu’à la fin de ce processus.

# Find deleted files that are still open
sudo lsof +L1 2>/dev/null | head

Le coupable habituel est un écrivain de journal encore actif ; redémarrez le service concerné (sudo systemctl restart <service>).

« No space left on device » alors que df affiche de l’espace libre

Probablement un épuisement des inodes, typique avec d’énormes quantités de petits fichiers (spools de courrier, couches de conteneurs).

# Check inode usage
df -i

Si IUse% est à 100 %, c’est votre problème ; la solution est le même type de nettoyage, sauf qu’il faut supprimer beaucoup de petits fichiers, et non de gros fichiers.

Automatiser le nettoyage

systemd-tmpfiles nettoie déjà /tmp et certains caches. Pour planifier le nettoyage du cache apt, ajoutez une entrée cron :

# Clean the apt cache every Sunday at 03:00
0 3 * * 0 root /usr/bin/apt clean

Enregistrez-la dans /etc/cron.d/apt-clean.

Voir aussi

• Disques, montage et fstab — partitions, formatage et montage au démarrage
• Optimisation des performances — htop et le moniteur système
• Journaux et journalctl — taille des journaux et rotation