Question 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. 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 seulement 12G sont utilisés (j'utilise -x à cause de certaines montures 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? lsof me montre pas de fichiers supprimés ouverts, lost+found est 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.


89
2018-05-30 12:29


origine


C’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éponse à OldTroll. - Chris Ting


Réponses:


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


87
2018-05-30 12:35



Vous pouvez trouver ces fichiers cachés sans avoir à démonter les répertoires. Regardez la réponse de Marcel G ci-dessous qui explique comment. - mhsekhavat
Vous devriez montrer les commandes CLI pour le faire dans votre réponse - Jonathan
VÉRIFIEZ même si vous pensez que cela n’a aucun sens pour vous! - Chris


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

Dans mon cas le df -h et du -sh incompatibles avec 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.

Ceci a été dépisté en courant lsof | grep "/var" | grep deleted où /var était la partition que j'avais besoin de 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), et libéré 2 Go d’espace disque, en permettant l’effacement des verrous des fichiers supprimés.


71
2018-03-12 11:10



Pour moi, les serrures n’étaient pas libérées même après avoir arrêté le programme (zombies?). j'ai dû kill -9 'pid' libérer les serrures. par exemple: pour votre httpd il aurait été kill -9 32617. - Micka
Note mineure: vous devrez peut-être courir lsof comme sudo ou pas tous les descripteurs de fichiers ouverts apparaîtront - 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 au redémarrage httpd l'espace n'est pas libéré. Quand j'ai couru /etc/init.d/rsyslog restart cela a fonctionné: D - Thanh Nguyen Van
Vous pouvez sauter les greps et juste faire lsof -a +L1 /var, où -a signifie ET toutes les conditions (la valeur par défaut est OU), +L1 signifie ne lister que les fichiers dont le nombre de liens est inférieur à 1 (c'est-à-dire les fichiers supprimés avec des descripteurs de fichiers ouverts), et /var contraint aux fichiers sous ce point de montage - kbolino


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.


40
2018-05-30 13:54



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 des diffs dans /var/lib/docker/aufs/diff/ - naught101


Voir quoi df -i dit. Il se peut que vous soyez à court d’inodes, ce qui peut se produire 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.


23
2018-05-30 14:10



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 l'écart entre eux est grand. Si vous écrivez un script qui résume la taille des fichiers et le comparez au du -s du même sous-arbre, vous allez avoir une bonne idée si c'est le cas ici. - Marcin


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, qui m'a montré quel programme contenait deux fichiers journaux très volumineux (totalisant 5 Go de ma partition racine disponible de 8 Go).


15
2017-11-14 18:15



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 ... - α 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 tenant toujours un gros fichier supprimé - user1965449
Ce fut le cas pour nous, une application Linux de traitement de journaux appelée Filebeat maintint les fichiers ouverts. - Pykler


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.


5
2018-05-30 12:51



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 relâcheraient pas les verrous des fichiers, je kill -9 'pid' libérer les verrous et récupérer l’espace disque. - Micka


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

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
 19M racine
 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.


4
2018-06-26 13:05



Pourquoi ne pas utiliser des outils plus simples comme baobab? (voir marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
Hm ls + xargs semble exagéré, du -sh /* fonctionne très bien par lui-même - ChrisWue
si vous ne connaissez pas ncdu ... vous me remercierez plus tard: dev.yorhel.nl/ncdu - Troy Folger


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 (recherchez en particulier les lignes se terminant par "(supprimé"))


3
2018-06-26 10:38



Merci! J'ai pu constater que le processus du serveur SFTP contenait le fichier supprimé - lyomi


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 de / usr et de / 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émonte la partition 50G incriminé, ouvre 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 toujours savoir comment faire en sorte que le journal vapeur ne devienne plus grand.


1
2018-05-04 18:01



Est-ce que cela vous est arrivé au travail? serverfault.com/help/on-topic - chicks
Non, juste sur mon ordinateur à la maison. - Justin Chadwick
xfs_fsr résolu ce problème pour nous - Druska


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
2018-06-21 10:33