Disque plein, du dit différent. Comment approfondir les recherches?

J'ai un disque SCSI dans un serveur (RAID matériel 1), 32G, système de fichiers ext3. dfme dit que le disque est plein à 100%. Si je supprime 1G, cela s’affiche correctement.

Cependant, si je lance un du -h -x /alors dume dit que seulement 12G sont utilisés (j'utilise en -xraison de certains montages Samba).

Ma question ne porte donc pas sur les différences subtiles entre les commandes du et de df, mais sur la façon dont je peux découvrir les causes de cette différence si importante.

J'ai redémarré la machine pour un fsck qui a eu des erreurs. Devrais-je courir badblocks? lsofme montre pas de fichiers supprimés ouverts, lost+foundest vide et il n'y a pas d'instruction évident warn / err / fail 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. Fréquemment, si vous montez un répertoire (par exemple un sambaf) sur un système de fichiers contenant déjà un fichier ou des répertoires, vous perdez la possibilité de voir ces fichiers, mais ils occupent toujours de l'espace sur le disque sous-jacent. J'ai eu des copies de fichiers alors qu'en mode mono-utilisateur dumpais des fichiers dans des répertoires que je ne pouvais pas voir sauf en mode utilisateur unique (car d'autres systèmes de répertoires étaient montés dessus).

Vous êtes tombé sur cette page lorsque vous essayez de localiser un problème sur un serveur local.

Dans mon cas, le df -het du -shincompatibles par environ 50% de la taille du disque dur.

Cela est dû au fait qu'apache (httpd) a conservé de gros fichiers journaux en mémoire, qui ont été supprimés du disque.

Cela a été dépisté en exécutant lsof | grep "/var" | grep deletedoù se /vartrouvait la partition que je devais nettoyer.

La sortie a montré des lignes comme ceci:
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), puis libérée de 2 Go d'espace disque en autorisant la suppression des verrous des fichiers supprimés.

Je suis d'accord avec la réponse de OldTroll comme cause la plus probable de votre espace "manquant".

Sous Linux, vous pouvez facilement remonter toute la partition racine (ou toute autre partition) à un autre endroit de votre système de fichiers, par exemple / mnt, par exemple.

mount -o bind / /mnt

alors vous pouvez faire un

du -h /mnt

et voir ce qui utilise votre espace.

Ps: désolé d'avoir ajouté une nouvelle réponse et non un commentaire, mais j'avais besoin d'un formatage pour que ce message soit lisible.

Voyez ce que df -idit. Il se peut que vous soyez à court d’inodes, ce qui peut arriver s’il ya un grand nombre de petits fichiers dans ce système de fichiers, qui utilise tous les inodes disponibles sans utiliser tout l’espace disponible.

Dans mon cas, cela concernait de gros fichiers supprimés. C'était assez pénible à résoudre avant de trouver cette page qui m'a mis sur le bon chemin.

J'ai finalement résolu le problème en utilisant lsof | grep deleted, ce qui m'a montré quel programme contenait deux très gros fichiers journaux (totalisant 5 Go de ma partition racine disponible de 8 Go).

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"

Ensuite, essayez d’éliminer tous les PID qui sont bloqués (cherchez en particulier les lignes se terminant par "(supprimé"))

C'est la méthode la plus simple que j'ai trouvée à ce jour pour trouver des fichiers volumineux!

Voici un exemple si votre montage racine est plein / (mount / root) Exemple:

cd / (donc vous êtes en root)

ls | xargs du -hs

Exemple de sortie:

 9.4M bin
 Démarrage 63M
 4.0K cgroup
 680K dev
 31M etc
 Maison 6.3G
 313M lib
 32M lib64
 16K perdu + trouvé
 61G médias
 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 course
 19M sbin
 4.0K selinux
 4.0K srv
 Magasin 25G
 26M tmp

alors vous remarquerez que le magasin est grand faire un cd / magasin

et courir à nouveau

ls | xargs du -hs

Exemple de sortie: 
 109M de sauvegarde
 358M Fnb
 4.0G iso
 8.0K ks
 16K perdu + trouvé
 Racine 47M
 11M scripts
 79M tmp
 21G vms

dans ce cas, le répertoire vms est le raccourci d’espace.

Pour moi, je devais exécuter sudo ducar il y avait une grande quantité de fichiers docker sous /var/lib/dockerlesquels un utilisateur non-sudo n'a pas l'autorisation de lire.

Une autre possibilité à prendre en compte - vous êtes presque certain de constater une différence importante si vous utilisez docker et que vous exécutez df / du dans un conteneur utilisant des montages de volume. Dans le cas d'un répertoire monté sur un volume sur l'hôte de menu fixe, df signalera les totaux df de l'hôte. Cela est évident si vous y réfléchissez, mais lorsque vous recevez un rapport sur "un conteneur qui remplit le disque!", Assurez-vous de vérifier la consommation d'espace de fichier du conteneur avec quelque chose comme du -hs <dir>.

Donc, j'ai eu ce problème dans Centos 7 aussi et j'ai trouvé une solution après avoir essayé un tas de choses comme bleachbit et le nettoyage / usr et / var alors qu'ils ne montraient qu'environ 7G chacun. Montrait toujours 50G de 50G utilisé dans la partition racine mais montrait seulement 9G d'utilisation de fichier. Ran un live ubuntu cd et démonté la partition 50G incriminé, a ouvert le terminal et a exécuté xfs_check et xfs_repair sur la partition. J'ai ensuite remonté la partition et mon répertoire lost + found a été étendu à 40G. Trié le + perdu par taille et trouvé un fichier journal de 38G pour Steam qui ne faisait que répéter une erreur mp3. Suppression du fichier volumineux et espace disponible maintenant. L'utilisation de mes disques est en accord avec la taille de la partition racine. J'aimerais quand même savoir comment faire en sorte que le journal vapeur ne devienne plus grand.

Si le disque monté est un dossier partagé sur une machine Windows, il semble alors que df affichera la taille et l'utilisation du disque entier sous 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.

Une situation similaire nous est arrivée en production: l’utilisation du disque a atteint 98%. L'enquête suivante a-t-elle:

a) df -ipour vérifier l'utilisation d'inode, l'utilisation d'inode était de 6%, donc pas de fichiers beaucoup plus petits

b) Monter rootet vérifier les fichiers cachés. Impossible de déposer des fichiers supplémentaires . dules résultats étaient les mêmes qu'auparavant mont.

c) Enfin, les nginxjournaux vérifiés . Il a été configuré pour écrire sur le disque, mais un développeur a supprimé le fichier journal directement, ce qui a permis nginxde conserver tous les journaux en mémoire. Comme le fichier a /var/log/nginx/access.logété supprimé du disque en utilisant, rmil n'était pas visible en utilisant, dumais le fichier était en cours d'accès nginxet par conséquent il était toujours maintenu ouvert

J'ai eu le même problème qui est 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 consistait en un contact d'assistance avec notre fournisseur VPS, qui a effectué un recalcul de quota et corrigé la différence d'espace entre df -het 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, pas sûr de vimcréer ce problème). Le fichier occupait 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

Ceci examine 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, la dernière entrée (la plus grande) ressemblait à ceci:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Cela signifie que le processus (PID) 12345 consomme 1.46G (la huitième colonne divisée par 1024³) de disque malgré le fait duqu’il n’a pas été remarqué. viest horrible à voir des fichiers extrêmement volumineux; même 100 Mo est grand pour cela. 1.5G (ou quelle que soit la taille du fichier) est ridicule.

La solution consistait à sudo kill -HUP 12345(si cela ne fonctionnait pas, je le ferais sudo kill 12345et si cela échouait également, le redouté kill -9entrerait en jeu).

Évitez les éditeurs de texte sur les gros fichiers. Exemples de solutions de contournement pour un écrémage 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 viewparce que vimc'est presque toujours mieux ... quand il est installé. N'hésitez pas à les diriger vers viewou à la vi -Rplace.

Si vous ouvrez un tel fichier à modifier réellement, considérer sedou awkou une autre approche programmatique.

vérifiez si votre serveur a l'agent ossec installé. Ou bien certains processus utilisent les fichiers journaux supprimés. Il y a longtemps, j'étais agent ossec.

vérifiez le / lost + found, j'ai eu un système (centos 7) et une partie du fichier dans le / lost + found a mangé tout l'espace.