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


110

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.


3
Ceci est très proche de la question: linux - du vs df difference ( serverfault.com/questions/57098/du-vs-df-difference ). La solution consistait à placer les fichiers sous un point de montage en répondant à OldTroll.
Chris Ting

Réponses:


95

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).


3
Vous pouvez trouver ces fichiers cachés sans avoir à démonter les répertoires. Jetez un oeil à la réponse de Marcel G ci-dessous qui explique comment.
Mhsekhavat

Vous devriez montrer les commandes de la CLI pour le faire dans votre réponse
Jonathan

1
VÉRIFIEZ même si vous pensez que cela n’a aucun sens pour vous!
Chris

1
Remarque: cette réponse parle des fichiers situés sous les points de montage (c'est-à-dire cachés dans le système de fichiers d'origine) et non entre les points de montage. (Ne soyez pas un idiot comme moi.)
mwfearnley

92

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.


Pour moi, les serrures n’étaient pas libérées même après avoir arrêté le programme (zombies?). Je devais kill -9 'pid'libérer les serrures. Par exemple: cela aurait été le cas pour votre httpd kill -9 32617.
Micka

6
Remarque mineure: vous devrez peut-être exécuter lsofau sudomoins tous les descripteurs de fichiers ouverts
ChrisWue

J'ai rencontré cela avec H2, qui ajoutait plusieurs concerts à un fichier journal chaque jour. Au lieu de redémarrer H2 (lent), j'ai utilisé sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd).
Desty

Dans mon cas, même lorsque l' httpdespace de redémarrage n'est pas libéré. Quand j'ai couru, /etc/init.d/rsyslog restartcela a fonctionné: D
Thanh Nguyen Van

2
Vous pouvez ignorer les opérations de grève et faire ce que vous voulez lsof -a +L1 /var, où -asignifie ET toutes les conditions (par défaut, OU), +L1signifie que seuls les fichiers avec un nombre de liens inférieur à 1 (c'est-à-dire des fichiers supprimés avec des descripteurs de fichiers ouverts) sont /varcontraints et que les fichiers situés sous ce point de montage sont limités
kbolino

52

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.


3
Merci beaucoup pour ce conseil. M'a permis de trouver et de supprimer mes gros fichiers "cachés" sans temps d'arrêt!
Choover

Merci - cela a montré que docker remplissait mon disque dur avec diffs/var/lib/docker/aufs/diff/
naught101

mount -o bind / /mntm'a donné une information supplémentaire que je cherchais. Merci!
Slavik Meltser

25

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.


1
La taille d'un fichier et la quantité d'espace qu'il prend sur un système de fichiers sont deux choses distinctes. Plus les fichiers sont petits, plus la différence entre eux est grande. Si vous écrivez un script qui résume la taille des fichiers et le comparez au du -smême sous-arbre, vous aurez une bonne idée si c'est le cas ici.
Marcin

24

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).


1
Cette réponse me fait me demander pourquoi vous stockez des fichiers journaux sur la partition racine, en particulier une aussi petite que ... mais à chacun, je suppose ...
un CVn

J'ai eu un problème similaire, j'avais redémarré toutes les applications qui utilisaient le fichier supprimé, je suppose qu'il y avait un processus zombie conservant encore un gros fichier supprimé
user1965449

Ce fut le cas pour nous, une application Linux de traitement de journal appelée Filebeat maintint les fichiers ouverts.
Pykler

@Pykler Pour nous, il s'agissait également de battements de fichiers. Merci pour le conseil!
Martijn Heemels le

7

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.


OP a déclaré qu'il avait redémarré le système et que le problème persistait.
OldTroll

J'avais des zombies qui ne libéraient pas les verrous sur les fichiers, je kill -9 'pid'leur demandais de les libérer et de récupérer de l'espace disque.
Micka

5

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é"))


Merci! J'ai pu constater que le processus du serveur SFTP
contenait

4

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.


1
Pourquoi ne pas utiliser des outils plus simples comme baobab? (voir marzocca.net/linux/baobab/baobab-getting-started.html )
Yvan

2
Hm ls+ xargssemble être une overkill, du -sh /*fonctionne très bien par lui
ChrisWue

1
si vous ne connaissez pas ncdu ... vous me remercierez plus tard: dev.yorhel.nl/ncdu
Troy Folger

3

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.


C'était mon problème. J'avais oublié d'avoir changé de système de stockage dans Docker et les anciens volumes traînaient toujours.
Richard Nienaber le

1

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>.


1

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.


Est-ce que cela vous est arrivé au travail? serverfault.com/help/on-topic
poussins

Non seulement sur mon ordinateur à la maison.
Justin Chadwick

3
xfs_fsrrésolu ce problème pour nous
Druska

0

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.


0

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


0

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 /.


0

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.


0

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.


1
OP a indiqué que la machine avait été redémarrée, il ne devrait donc plus rester de fichiers supprimés.
RalfFriedl

-3

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.


Comment cela expliquerait-il la différence d'utilisation signalée du disque décrite dans la question ?
Roaima
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.