Il faut distinguer saturation en espace, saturation en inodes et fichiers supprimés encore ouverts avant de nettoyer un serveur Linux.
Étapes à suivre
-
1
Mesurer les volumes
Utilisez df -h pour localiser le système de fichiers saturé.
-
2
Vérifier les inodes
Utilisez df -i pour exclure un manque d’inodes.
-
3
Chercher les gros dossiers
Utilisez du sur le point de montage concerné.
-
4
Rechercher les fichiers ouverts supprimés
lsof peut révéler de gros fichiers encore occupés par un processus.
-
5
Nettoyer de façon ciblée
Traitez logs, caches ou données uniquement après identification.
Commandes utiles
df -h
df -i
sudo du -xhd1 /var | sort -h
sudo lsof +L1
À retenir
- Ne supprimez pas aveuglément /var/lib ou les fichiers d’une base de données.
- Un fichier supprimé mais encore ouvert continue d’occuper de l’espace.
- Vérifiez logrotate si les logs sont la cause récurrente.
Stockage Linux : distinguer blocs, inodes et fichiers supprimés encore ouverts
Repères techniques
- df mesure l’espace du filesystem alors que du estime les fichiers visibles ; un écart important peut venir de fichiers supprimés encore ouverts.
- df -i détecte l’épuisement des inodes, qui peut bloquer toute création de fichier même avec des Go libres.
- Un filesystem passé read-only peut être la protection du noyau après des erreurs I/O ou filesystem ; remonter rw sans comprendre la cause est risqué.
Tri stockage
Comparer blocs, inodes, gros répertoires et fichiers supprimés encore ouverts.
df -hT
df -i
du -xhd1 /var | sort -h
lsof +L1Pièges spécifiques
- Lancer rm sur /var/lib ou Docker sans identifier le propriétaire des données peut casser un service.
- fsck ne doit pas être lancé sur un filesystem monté en écriture sauf cas/documentation spécifique.
Comment valider
- La cause de consommation ou de passage read-only est identifiée dans les logs/kernel.
- Après correction, blocs et inodes disposent d’une marge et aucune nouvelle erreur I/O n’apparaît.
Preuves et vérifications
df mesure l’espace du filesystem alors que du estime les fichiers visibles ; un écart important peut venir de fichiers supprimés encore ouverts. df -i détecte l’épuisement des inodes, qui peut bloquer toute création de fichier même avec des Go libres.
Contrôle de résultat
La cause de consommation ou de passage read-only est identifiée dans les logs/kernel. Après correction, blocs et inodes disposent d’une marge et aucune nouvelle erreur I/O n’apparaît.
Point d’attention
Lancer rm sur /var/lib ou Docker sans identifier le propriétaire des données peut casser un service. Un filesystem passé read-only peut être la protection du noyau après des erreurs I/O ou filesystem ; remonter rw sans comprendre la cause est risqué.
Concepts liés
Référence primaire : Linux man-pages — df.