Disque plein, du dit différent. Comment approfondir l'enquête?
J'ai un disque SCSI dans un serveur (matériel Raid 1), 32G, système de fichiers ext3. df me dit que le disque est plein à 100%. Si je supprime 1G, cela s'affiche correctement.
Cependant, si je lance un du -h -x / puis du me dit que seuls 12G sont utilisés (j'utilise -x à cause de certaines montures Samba).
Donc ma question n'est pas sur les différences subtiles entre les commandes du et df mais sur la façon dont je peux trouver les causes de cette énorme différence?
J'ai redémarré la machine pour un fsck qui s'est passé sans erreurs. Dois-je exécuter badblocks? lsof ne me montre aucun fichier supprimé ouvert, lost+found est vide et il n'y a pas d'instruction warn/err/fail évidente dans le fichier de messages.
N'hésitez pas à demander plus de détails sur la configuration.
Recherchez les fichiers situés sous les points de montage. Souvent, si vous montez un répertoire (par exemple un sambafs) sur un système de fichiers qui contenait déjà un fichier ou des répertoires, vous perdez la possibilité de voir ces fichiers, mais ils consomment toujours de l'espace sur le disque sous-jacent. J'ai eu des copies de fichiers en mode de vidage en mode utilisateur unique dans des répertoires que je ne pouvais pas voir sauf en mode utilisateur unique (en raison du fait que d'autres systèmes de répertoires étaient montés dessus).
Je suis juste tombé sur cette page en essayant de retrouver un problème sur un serveur local.
Dans mon cas, df -h Et du -sh Ne correspondaient pas à environ 50% de la taille du disque dur.
Cela était dû au fait qu'Apache (httpd) conservait de gros fichiers journaux en mémoire qui avaient été supprimés du disque.
Cela a été détecté en exécutant lsof | grep "/var" | grep deleted Où /var Était la partition dont j'avais besoin pour nettoyer.
La sortie a montré des lignes comme celle-ci:httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/Apache/awstats_log (deleted)
La situation a ensuite été résolue en redémarrant Apache (service httpd restart) Et en libérant 2 Go d'espace disque, en autorisant la suppression des verrous sur les fichiers supprimés.
Je suis d'accord avec la réponse d'OldTroll comme cause la plus probable de votre espace "manquant".
Sous Linux, vous pouvez facilement remonter la partition racine entière (ou toute autre partition d'ailleurs) à un autre endroit de votre système de fichiers, par exemple/mnt, il suffit d'émettre un
mount -o bind / /mnt
alors vous pouvez faire
du -h /mnt
et voyez ce qui utilise votre espace.
Ps: désolé d'avoir ajouté une nouvelle réponse et non un commentaire, mais j'avais besoin d'une mise en forme pour que ce post soit lisible.
Voir quoi df -i dit. Il se peut que vous soyez à court d'inodes, ce qui peut arriver s'il y a un grand nombre de petits fichiers dans ce système de fichiers, qui utilise tous les inodes disponibles sans consommer tout l'espace disponible.
Dans mon cas, cela avait à voir avec de gros fichiers supprimés. C'était assez pénible à résoudre avant de trouver cette page, ce qui m'a mis sur la bonne voie.
J'ai finalement résolu le problème en utilisant lsof | grep deleted, qui m'a montré quel programme contenait deux très gros fichiers journaux (totalisant 5 Go de ma partition racine de 8 Go disponible).
Les fichiers ouverts par un programme ne disparaissent pas réellement (arrêtez de consommer de l'espace disque) lorsque vous les supprimez, ils disparaissent lorsque le programme les ferme. Un programme peut avoir un énorme fichier temporaire que vous (et du) ne pouvez pas voir. S'il s'agit d'un programme zombie, vous devrez peut-être redémarrer pour effacer ces fichiers.
Essayez ceci pour voir si un processus mort/bloqué est verrouillé tout en écrivant sur le disque: lsof | grep "/ mnt"
Essayez ensuite de supprimer tous les PID bloqués (recherchez en particulier les lignes se terminant par "(supprimé"))
Pour moi, je devais exécuter Sudo du car il y avait une grande quantité de fichiers docker sous /var/lib/docker qu'un utilisateur non Sudo n'est pas autorisé à lire.
C'est la méthode la plus simple que j'ai trouvée à ce jour pour trouver de gros fichiers!
Voici un exemple si votre montage racine est complet/(montage/racine) Exemple:
cd / (donc vous êtes en root)
ls | xargs du -hs
Exemple de sortie:
9,4M bin 63M boot 4.0K cgroup 680K dev 31M etc 6.3G home 313M lib 32M lib64 16K perdu + trouvé Support 61G 4.0K mnt 113M opt Du: impossible d'accéder à ` proc/6102/task/6102/fd/4 ': Aucun fichier ou répertoire de ce type 0 proc Racine 19M 840K exécuté 19M sbin 4.0K selinux 4.0K srv Magasin 25G 26M tmp
alors vous remarquerez que store is large do a cd/store
et courir à nouveau
ls | xargs du -hs
Exemple de sortie: Sauvegarde 109M 358M fnb ISO 4.0G 8.0K ks 16K perdu + trouvé 47M racine 11M scripts 79M tmp 21G vms
dans ce cas, le répertoire vms est le porc d'espace.
J'ai donc eu ce problème dans Centos 7 également et j'ai trouvé une solution après avoir essayé un tas de choses comme Bleachbit et le nettoyage/usr et/var même si elles ne montraient que 7G chacune. Affiche toujours 50 Go de 50 Go utilisés dans la partition racine, mais ne montre que 9 Go d'utilisation de fichier. Exécuté un cd ubuntu en direct et démonté la partition 50G incriminée, ouvert le terminal et exécuté xfs_check et xfs_repair sur la partition. J'ai ensuite remonté la partition et mon répertoire lost + found avait été étendu à 40G. Trié le + perdu trouvé par taille et trouvé un fichier journal de texte 38G pour Steam qui a finalement répété une erreur mp3. Suppression du gros fichier et maintenant de l'espace et l'utilisation de mes disques correspond à la taille de ma partition racine. J'aimerais encore savoir comment faire en sorte que le journal Steam ne grossisse plus à nouveau.
Une autre possibilité à considérer - vous êtes presque assuré de voir une grande différence si vous utilisez docker, et vous exécutez df/du à l'intérieur d'un conteneur qui utilise des montages de volume. Dans le cas d'un répertoire monté sur un volume sur l'hôte docker, df indiquera les totaux df de l'hôte. C'est évident si vous y pensez, mais lorsque vous obtenez un rapport d'un "conteneur emballé remplissant le disque!", Assurez-vous de vérifier la consommation d'espace fichier du conteneur avec quelque chose comme du -hs <dir>.
Dans mon cas, lsof n'a pas aidé. J'ai pu retrouver cela parce que j'avais monté des images de disque en utilisant losetup comme périphériques de boucle. Même après avoir démonté ces périphériques et supprimé les images correspondantes, il y avait des processus qui maintenaient une sorte de référence indirecte aux images du disque.
Donc en bref, Sudo ps -ef|grep loop puis Sudo losetup -d /dev/loopX. Ce n'est pas une réponse directe à la raison pour laquelle du et df ne sont pas d'accord, mais cela m'est venu assez souvent pour que je puisse enfin comprendre la raison pour laquelle ce qui était différent de toute réponse que j'ai pu trouver.
J'ai eu le même problème que celui mentionné dans ce sujet, mais dans un VPS. J'ai donc testé tout ce qui est décrit dans cette rubrique mais sans succès. La solution était un contact de support avec notre fournisseur VPS qui a effectué un recalcul de quota et corrigé la différence d'espace de df -h et du-sh /.
J'ai rencontré ce problème sur une boîte FreeBSD aujourd'hui. Le problème était qu'il s'agissait d'un artefact de vi (pas vim, je ne sais pas si vim créerait ce problème). Le fichier consommait de l'espace mais n'avait pas été entièrement écrit sur le disque.
Vous pouvez vérifier cela avec:
$ fstat -f /path/to/mount/point |sort -nk8 |tail
Cela regarde tous les fichiers ouverts et les trie (numériquement via -n) Par la 8ème colonne (clé, -k8), Montrant les dix derniers éléments.
Dans mon cas, l'entrée finale (la plus grande) ressemblait à ceci:
bob vi 12345 4 /var 97267 -rwx------ 1569454080 rw
Cela signifiait que le processus (PID) 12345 consommait 1,46 G (la huitième colonne divisée par 1024³) de disque malgré le manque de du le remarquant. vi est horrible à voir des fichiers extrêmement volumineux; même 100 Mo sont gros pour cela. 1.5G (ou quelle que soit la taille de ce fichier) est ridicule.
La solution était de Sudo kill -HUP 12345 (Si cela ne fonctionnait pas, je Sudo kill 12345 Et si cela échouait également, le redoutable kill -9 Entrerait en jeu).
Évitez les éditeurs de texte sur des fichiers volumineux. Exemples de solutions de contournement pour un survol rapide:
En supposant des longueurs de ligne raisonnables:
{ head -n1000 big.log; tail -n1000 big.log } |vim -R -wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -
En supposant des lignes déraisonnablement grandes:
{ head -c8000 big.log; tail -c8000 big.log } |vim -R -
Ceux-ci utilisent vim -R À la place de view car vim est presque toujours meilleur ... lorsqu'il est installé. N'hésitez pas à les canaliser dans view ou vi -R À la place.
Si vous ouvrez un fichier si volumineux pour le modifier, envisagez sed ou awk ou une autre approche programmatique.
vérifiez si votre serveur a installé l'agent ossec. Ou un processus utilise les fichiers journaux supprimés. Il y a quelque temps, j'étais agent ossec.
Une chose similaire nous est arrivée en production, l'utilisation du disque est passée à 98%. L'enquête suivante a-t-elle:
une) df -i pour vérifier l'utilisation des inodes, l'utilisation des inodes était de 6% donc pas de fichiers beaucoup plus petits
b) Monter root et vérifier les fichiers cachés. Impossible de déposer des fichiers supplémentaires. du les résultats étaient les mêmes qu'avant le montage.
c) Enfin, vérifié nginxlogs. Il a été configuré pour écrire sur le disque, mais un développeur a supprimé le fichier journal en provoquant directement nginx à conserver tous les journaux en mémoire. Comme le fichier /var/log/nginx/access.log a été supprimé du disque à l'aide de rm il n'était pas visible à l'aide de du mais le fichier était accessible par nginx et il était donc toujours conservé open =
si le disque monté est un dossier partagé sur une machine Windows, il semble que df affichera la taille et l'utilisation du disque de l'intégralité du disque Windows, mais du ne montrera que la partie du disque à laquelle vous avez également accès. (et est monté). dans ce cas, le problème doit être résolu sur la machine Windows.