L'utilisation de l'espace disque ne correspond pas à df & du

J'essaie de libérer de l'espace disque - si je fais un df -h, j'ai un système de fichiers appelé / dev / mapper / vg00-var qui dit que sa 4G, 3,8 G utilisée, 205M à gauche.

Cela correspond à mon répertoire / var.

Si je descends dans / var et le fais du -kscxh *, le total est 2.1G

2.1G + 200M gratuit = 2.3G ... Donc ma question est, où est le 1.7G restant?

linux du df

— Codecraft
source

Que du -shx /vardit-on?

— Kyle Smith

Vous pouvez également avoir supprimé des fichiers dont les descripteurs de fichiers sont ouverts. Le système d'exploitation ne libérera pas l'espace tant que les poignées ne seront pas fermées, mais vous ne les verrez pas avec "du". Vous pouvez exécuter "lsof / var | grep supprimé" (ou quelque chose de similaire) pour les voir. Ce ne serait en fait pas une découverte surprenante dans, disons, / var / log, si les journaux sont tournés mais que le processus de journalisation n'est pas HUP correctement.

— cjc

J'avais supprimé certains fichiers journaux qui étaient devenus fous, il semblait qu'ils n'avaient pas tourné, mais de toute façon, j'avais un mot de passe d'un ami 'reboot' - je pensais qu'il était sarcastique mais apparemment pas :) ont retrouvé mon espace disque .... catastrophe évitée (pour l'instant).

— Codecraft

@Codecraft Oui, le redémarrage effacera définitivement tous les descripteurs de fichiers ouverts, bien que ce soit un peu comme casser un œuf avec un marteau.

— cjc

@cjc tant que j'obtiens la bonté jaune ...! Avez-vous des suggestions sur la façon de nettoyer les poignées de fichiers ouvertes sans marteler mon œuf?

— Codecraft

Vous avez probablement supprimé un gros fichier journal, un fichier de base de données ou quelque chose de similaire, attendant que le processus contenant le fichier le libère.

Sous Linux, une suppression de fichier dissocie simplement le fichier. Il est en fait supprimé lorsqu'il n'y a plus de descripteurs de fichiers connectés à ce fichier. Donc, si vous avez un fichier journal de 2 Go que vous supprimez manuellement avec rm, l'espace disque ne sera pas libéré tant que vous ne redémarrez pas le démon syslog (ou ne lui envoyez pas de HUPsignal).

Essayer

lsof -n | grep -i deleted

et voyez si vous avez encore des fichiers zombies supprimés qui flottent.

— Janne Pikkarainen
source

Je n'ai pas réussi à exécuter votre commande, mais ce que vous avez dit semble avoir frappé - j'avais tué manuellement certains journaux devenus fous, et à la fin, un redémarrage a fait recalculer l'espace disque et l'afficher correctement.

— Codecraft

Cela a fonctionné pour nous avec les journaux Apache remplissant le répertoire / var / log / apache /. Ainsi, vous n'aurez peut-être pas à redémarrer l'ensemble de votre serveur, ni syslog, juste le service que vous trouverez dans la sortie de la commande ci-dessus.

— Yvan

Je viens de l'avoir nous-mêmes. Nous avons eu le tomcat6 catalina.out pas attrapé par logrotate, l'avons-nous supprimé quand il a atteint 4Gb et fixe logrotate. Quelques semaines plus tard, nous nous sommes demandé pourquoi le 4Gb n'était pas revenu. Cette lsofcommande a montré que nous avions beaucoup de fichiers tomcat en attente de suppression. Redémarrage de Tomcat et tout à coup, nous avons des tonnes d'espace de retour!

— Nick

Enfin une réponse qui a fonctionné pour moi. PostgreSQL s'est planté et a laissé des connexions ouvertes à 400 Go (!!!) de fichiers non liés sur un disque de 1 To. Le redémarrage de Postgres l'a corrigé.

— sudo