Afficher rapidement l’utilisation des systèmes de fichiers sous Linux.
Étapes à suivre
-
1
Ouvrir un terminal
Connectez-vous localement ou via SSH.
-
2
Afficher les volumes
Utilisez df -h.
-
3
Repérer les partitions presque pleines
Observez la colonne Use%.
-
4
Identifier les gros répertoires si nécessaire
Utilisez du de manière ciblée sur le volume concerné.
Commandes utiles
df -h
du -xh --max-depth=1 /var 2>/dev/null | sort -h
À retenir
- N’exécutez pas des recherches du complètes sur un serveur chargé sans considérer l’impact I/O.
- Les fichiers supprimés mais encore ouverts peuvent continuer à occuper de l’espace.
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.