Frage Festplatte voll, du sagst anders. Wie weiter zu untersuchen?


Ich habe eine SCSI-Festplatte in einem Server (Hardware Raid 1), 32G, ext3-Dateisystem. df sagt mir, dass die Platte zu 100% voll ist. Wenn ich 1G lösche, wird dies korrekt angezeigt.

Wenn ich jedoch ein laufe du -h -x / dann du sagt mir, dass nur 12G verwendet werden (ich benutze -x wegen einiger Samba-Mounts).

Meine Frage geht also nicht um subtile Unterschiede zwischen den Befehlen du und df, sondern darum, wie ich herausfinden kann, was diesen großen Unterschied verursacht?

Ich startete die Maschine für einen fsck, der ohne Fehler ging. Sollte ich laufen badblocks? lsof zeigt mir keine offenen gelöschten Dateien, lost+found ist leer und es gibt keine offensichtliche warn / err / fail-Anweisung in der Nachrichtendatei.

Fragen Sie nach weiteren Details des Setups.


89
2018-05-30 12:29


Ursprung


Das ist sehr nah an der Frage: linux - du vs df Unterschied (serverfault.com/questions/57098/du-vs-df-difference). Die Lösung waren Dateien unter einem Mount-Punkt, als OldTroll geantwortet hat. - Chris Ting


Antworten:


Suchen Sie nach Dateien, die sich unter Bereitstellungspunkten befinden. Wenn Sie ein Verzeichnis (zB ein Sambafs) auf einem Dateisystem mounten, das bereits eine Datei oder Verzeichnisse darunter hatte, verlieren Sie zwar die Fähigkeit, diese Dateien zu sehen, aber sie verbrauchen immer noch Speicherplatz auf dem zugrunde liegenden Datenträger. Ich hatte Dateikopien, während ich im Einzelbenutzermodus Dateien in Verzeichnisse abspeicherte, die ich außer im Einzelbenutzermodus nicht sehen konnte (aufgrund der Tatsache, dass andere Verzeichnissysteme über ihnen montiert wurden).


87
2018-05-30 12:35



Sie können diese versteckten Dateien finden, ohne Verzeichnisse abmelden zu müssen. Sehen Sie sich unten die Antwort von Marcel G an, die erklärt, wie. - mhsekhavat
Sie sollten die CLI-Befehle anzeigen, um dies in Ihrer Antwort zu tun - Jonathan
Tue selbst wenn du denkst, dass es für dich keinen Sinn ergibt! - Chris


Ich bin gerade auf dieser Seite gestolpert, als ich versuchte, ein Problem auf einem lokalen Server aufzuspüren.

In meinem Fall die df -h und du -sh nicht übereinstimmend um etwa 50% der Festplattengröße.

Dies wurde dadurch verursacht, dass Apache (httpd) große Protokolldateien im Speicher speicherte, die von der Festplatte gelöscht worden waren.

Dies wurde durch Laufen festgestellt lsof | grep "/var" | grep deleted woher /var war die Partition, die ich aufräumen musste.

Die Ausgabe zeigte Zeilen wie folgt:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Die Situation wurde dann durch Neustart von Apache (service httpd restart) und löschte 2 GB Speicherplatz, indem die Sperren für gelöschte Dateien gelöscht werden.


71
2018-03-12 11:10



Für mich wurden die Schlösser auch nach dem Stoppen des Programms nicht freigegeben (Zombies?). Ich musste kill -9 'pid' um die Schlösser zu lösen. zB: Für dein httpd wäre es gewesen kill -9 32617. - Micka
Kleiner Hinweis: Sie müssen möglicherweise laufen lsof wie sudo oder nicht alle offenen Dateideskriptoren werden angezeigt - ChrisWue
Ich stieß auf dieses Problem mit H2, das jeden Tag mehrere Gigs zu einer Logdatei hinzufügte. Anstatt H2 (langsam) neu zu starten, habe ich verwendet sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd). - Desty
In meinem Fall, auch beim Neustart httpd Speicherplatz wird nicht freigegeben. Als ich rannte /etc/init.d/rsyslog restart es hat funktioniert: D - Thanh Nguyen Van
Sie können die Greps überspringen und einfach tun lsof -a +L1 /var, woher -a bedeutet AND alle Bedingungen (Standard ist OR), +L1 bedeutet, dass nur Dateien mit Link-Zählwerten von weniger als 1 aufgelistet werden (d. h. gelöschte Dateien mit offenen Dateideskriptoren) und /var beschränkt sich auf Dateien unter diesem Einhängepunkt - kbolino


Ich stimme der Antwort von OldTroll als wahrscheinlichster Grund für dein "fehlendes" Feld zu.

Unter Linux können Sie die ganze root-Partition (oder jede andere Partition für diese Angelegenheit) einfach an eine andere Stelle in Ihrem Dateisystem zurückspeichern, sagen wir / mnt. Geben Sie einfach a ein

mount -o bind / /mnt

dann kannst du es tun

du -h /mnt

und sehen Sie, was Ihren Raum verbraucht.

Ps: Es tut mir leid, dass ich eine neue Antwort und keinen Kommentar hinzugefügt habe, aber ich brauchte etwas Formatierung, damit dieser Beitrag lesbar ist.


40
2018-05-30 13:54



Vielen Dank für diesen Tipp. Erlaubt mir, meine großen, "versteckten" Dateien ohne Ausfallzeiten zu finden und zu löschen! - choover
Danke - das hat gezeigt, dass der Docker meine Festplatte mit Diffs auffüllt /var/lib/docker/aufs/diff/ - naught101


Sieh was df -i sagt. Es könnte sein, dass Sie keine Inodes mehr haben, was passieren kann, wenn eine große Anzahl von kleinen Dateien in diesem Dateisystem vorhanden sind, die alle verfügbaren Inodes verbrauchen, ohne den gesamten verfügbaren Platz zu verbrauchen.


23
2018-05-30 14:10



Die Größe einer Datei und der Platzbedarf eines Dateisystems sind zwei verschiedene Dinge. Je kleiner die Dateien sind, desto größer ist die Diskrepanz zwischen ihnen. Wenn Sie ein Skript schreiben, das die Größe von Dateien zusammenfasst und es mit dem vergleichen du -s aus dem gleichen Unterbaum wirst du eine gute Idee bekommen, wenn das hier der Fall ist. - Marcin


In meinem Fall hatte das mit großen gelöschten Dateien zu tun. Es war ziemlich schmerzhaft zu lösen, bevor ich diese Seite fand, die mich auf den richtigen Weg brachte.

Ich löste das Problem schließlich mit Hilfe von lsof | grep deleted, die mir zeigte, welches Programm zwei sehr große Protokolldateien enthielt (insgesamt 5 GB meiner verfügbaren 8 GB großen Root-Partition).


15
2017-11-14 18:15



Diese Antwort lässt mich wundern, warum Sie Log-Dateien auf der Root-Partition speichern, besonders eine, die klein ist ... aber zu jeder ihren eigenen, nehme ich an ... - α CVn
Ich hatte ein ähnliches Problem, ich hatte alle Anwendungen neu gestartet, die die gelöschte Datei verwendeten, ich denke, es gab einen Zombie-Prozess, der sich immer noch an einer großen gelöschten Datei festhielt - user1965449
Dies war der Fall für uns, eine Log-Processing-Linux-App namens FileBeat Dateien geöffnet gehalten. - Pykler


Dateien, die von einem Programm geöffnet werden, gehen nicht wirklich verloren (verbrauchen keinen Speicherplatz mehr), wenn Sie sie löschen, sie verschwinden, wenn das Programm sie schließt. Ein Programm hat möglicherweise eine große temporäre Datei, die Sie (und du) nicht sehen können. Wenn es sich um ein Zombie-Programm handelt, müssen Sie möglicherweise neu starten, um diese Dateien zu löschen.


5
2018-05-30 12:51



OP sagte, er habe das System neu gestartet und das Problem bestehe weiterhin. - OldTroll
Ich hatte Zombies, die die Schlösser der Dateien nicht freigeben würden, ich kill -9 'pid' Sie geben die Sperren frei und holen den Speicherplatz zurück. - Micka


Dies ist die einfachste Methode, die ich gefunden habe, um große Dateien zu finden!

Hier ist ein Beispiel, wenn Ihr Root-Mount voll ist / (mount / root) Beispiel:

cd / (Sie sind also in der Wurzel)

ls | xargs du -hs

Beispielausgabe:

 9.4M bin
 63M Boot
 4.0K Gruppe
 680K Entwickler
 31M usw
 6.3G nach Hause
 313M lib
 32M lib64
 16K verloren + gefunden
 61G Medien
 4.0K mnt
 113M opt
 du: kann nicht auf `proc / 6102 / task / 6102 / fd / 4 'zugreifen: Keine solche Datei oder Verzeichnis
 0 proz
 19M Wurzel
 840K laufen
 19 Msbin
 4,0 K selinux
 4.0K srv
 25G Geschäft
 26M tmp

dann würdest du das bemerken Geschäft ist groß tun a CD / Laden

und lauf noch einmal

ls | xargs du -hs

Beispielausgabe:
 109M Backup
 358M Fnb
 4.0G iso
 8.0K ks
 16K verloren + gefunden
 47M Wurzel
 11 Millionen Skripte
 79M tmp
 21G vms

In diesem Fall ist das vms-Verzeichnis das Space-Hog.


4
2018-06-26 13:05



Warum nicht einfachere Tools wie baobab? (sehen marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
Hm ls + xargs scheint wie Overkill, du -sh /* funktioniert von selbst gut - ChrisWue
wenn du nichts über ncdu weißt ... wirst du mir später danken: dev.yorhel.nl/ncdu - Troy Folger


Probieren Sie dies aus, um zu sehen, ob ein Prozess "Dead / Hung" gesperrt ist, während Sie noch auf den Datenträger schreiben: lsof | grep "/ mnt"

Versuchen Sie dann, alle blockierten PIDs zu löschen (achten Sie besonders auf Zeilen mit der Endung "(deleted"))


3
2018-06-26 10:38



Vielen Dank! Ich konnte feststellen, dass der SFTP-Serverprozess die gelöschte Datei enthielt - lyomi


Also hatte ich dieses Problem auch in Centos 7 und fand eine Lösung, nachdem ich eine Menge Sachen wie Bleichmittel und Reinigen / usr und / var probiert hatte, obwohl sie nur etwa 7G pro Stück zeigten. War immer noch 50G von 50G in der Root-Partition verwendet, zeigte aber nur 9G Dateinutzung. Ran eine Live-Ubuntu-CD und abgehängt die beleidigende 50G-Partition, geöffnet Terminal und rannte xfs_check und xfs_repair auf der Partition. Ich habe dann die Partition neu gemountet und mein lost + found-Verzeichnis wurde auf 40G erweitert. Sortierte die verlorene + gefunden nach Größe und fand eine 38G Text Log-Datei für Dampf, die schließlich nur einen MP3-Fehler wiederholt. Entfernte die große Datei und habe jetzt Speicherplatz und meine Festplattennutzung stimmt mit meiner Root-Partitionsgröße überein. Ich würde immer noch gerne wissen, wie man den Dampfbalken nicht wieder so groß werden lässt.


1
2018-05-04 18:01



Ist Ihnen das bei der Arbeit passiert? serverfault.com/help/on-topic - chicks
Nein, nur auf meinem Computer zu Hause. - Justin Chadwick
xfs_fsr behebt dieses Problem für uns - Druska


Wenn der bereitgestellte Datenträger ein freigegebener Ordner auf einem Windows-Rechner ist, scheint df die Größe und den Festplattenverbrauch des gesamten Windows-Datenträgers anzuzeigen, aber du zeigt nur den Teil des Datenträgers an, auf den du Zugriff hast. (und ist montiert). Also in diesem Fall muss das Problem auf der Windows-Maschine behoben werden.


0
2018-06-21 10:33