it-swarm.com.de

Festplatte voll, du erzählt anders. Wie weiter zu untersuchen?

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

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

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

Ich habe den Computer für einen fsck neu gestartet, bei dem keine Fehler aufgetreten sind. Soll ich badblocks ausführen? lsof zeigt mir keine geöffneten 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.

123
initall

Suchen Sie nach Dateien unter den Einhängepunkten. Wenn Sie ein Verzeichnis (z. B. ein Sambafs) in ein Dateisystem einbinden, in dem sich bereits eine Datei oder Verzeichnisse befinden, verlieren Sie häufig die Fähigkeit, diese Dateien anzuzeigen, aber sie belegen immer noch Speicherplatz auf der zugrunde liegenden Festplatte. Ich hatte Dateikopien im Einzelbenutzermodus, um Dateien in Verzeichnisse zu kopieren, die ich nur im Einzelbenutzermodus sehen konnte (da andere Verzeichnissysteme darauf gemountet waren).

98
OldTroll

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

In meinem Fall stimmen df -h Und du -sh Um etwa 50% der Festplattengröße nicht überein.

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

Dies wurde durch Ausführen von lsof | grep "/var" | grep deleted Aufgespürt, wobei /var Die Partition war, die ich zum Bereinigen benötigte.

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

Die Situation wurde dann durch einen Neustart von Apache (service httpd restart) Gelöst und 2 GB Festplattenspeicher freigegeben, indem die Sperren für gelöschte Dateien aufgehoben wurden.

101
KHobbits

Ich stimme der Antwort von OldTroll als wahrscheinlichste Ursache für Ihren "fehlenden" Speicherplatz zu.

Unter Linux können Sie die gesamte Root-Partition (oder eine andere Partition) problemlos an einer anderen Stelle in Ihrem Dateisystem erneut bereitstellen, z. B./mnt. Geben Sie einfach a aus

mount -o bind / /mnt

dann kannst du a machen

du -h /mnt

und sehen, was Ihren Platz belegt.

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

56
Marcel G

Sehen Sie, was df -i sagt. Es kann sein, dass Sie keine Inodes mehr haben. Dies kann vorkommen, wenn sich in diesem Dateisystem eine große Anzahl kleiner Dateien befindet, die alle verfügbaren Inodes verbrauchen, ohne den gesamten verfügbaren Speicherplatz zu belegen.

26
eirescot

In meinem Fall hatte dies 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 habe das Problem schließlich mit lsof | grep deleted Gelöst, was mir zeigte, welches Programm zwei sehr große Protokolldateien enthielt (insgesamt 5 GB meiner verfügbaren 8 GB Root-Partition).

26
Adrian

Dateien, die von einem Programm geöffnet werden, werden beim Löschen nicht mehr gelöscht (es wird kein Speicherplatz mehr belegt), sondern beim Schließen des Programms. Ein Programm verfügt möglicherweise über 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 einen Neustart durchführen, um diese Dateien zu löschen.

7
Paul Tomblin

Versuchen Sie dies, um festzustellen, ob ein Dead/Hung-Prozess gesperrt ist, während noch auf die Festplatte geschrieben wird: lsof | grep "/ mnt"

Versuchen Sie dann, festsitzende PIDs zu entfernen (achten Sie insbesondere auf Zeilen, die mit "(gelöscht") enden).

5
Phirsk

Für mich musste ich Sudo du Ausführen, da es unter /var/lib/docker Eine große Anzahl von Docker-Dateien gab, die ein Nicht-Sudo-Benutzer nicht lesen darf.

5
jobevers

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

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

cd / (also bist du in root)

ls | xargs du -hs

Beispielausgabe:

 9.4M bin 
 63M boot 
 4.0K cgroup 
 680K dev 
 31M etc 
 6.3G home 
 313M lib 
 32M lib64 
 16K verloren + gefunden 
 61G Medien 
 4.0K mnt 
 113M opt 
 Du: kann nicht auf `zugreifen proc/6102/task/6102/fd/4 ': Keine solche Datei oder kein solches Verzeichnis 
 0 proc 
 19M root 
 840K run 
 19M sbin 
 4.0K selinux 
 4.0K srv 
 25G store 
 26M tmp 

dann würden Sie feststellen, dass store groß ist do a cd/store

und wieder laufen

ls | xargs du -hs

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

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

4
Riaan

Also hatte ich dieses Problem auch in Centos 7 und fand eine Lösung, nachdem ich ein paar Sachen wie Bleachbit und Cleaning/usr und/var ausprobiert hatte, obwohl sie jeweils nur etwa 7G zeigten. Zeigte immer noch 50G von 50G, die in der Root-Partition verwendet wurden, aber nur 9G der Dateinutzung. Lief eine Live-Ubuntu-CD und löste die fehlerhafte 50G-Partition, öffnete das Terminal und führte xfs_check und xfs_repair auf der Partition aus. Ich habe dann die Partition erneut bereitgestellt und mein Fundbüro wurde auf 40 GB erweitert. Sortierte das verlorene + nach Größe gefunden und fand eine 38G-Textprotokolldatei für Steam, die schließlich nur einen MP3-Fehler wiederholte. Die große Datei wurde entfernt und jetzt ist Speicherplatz vorhanden. Die Verwendung meiner Festplatten stimmt mit der Größe meiner Root-Partition überein. Ich würde immer noch gerne wissen, wie ich das Steam-Protokoll dazu bringen kann, nicht wieder so groß zu werden.

1
Justin Chadwick

Eine weitere Möglichkeit, die Sie in Betracht ziehen sollten: Wenn Sie Docker verwenden, wird fast garantiert eine große Diskrepanz festgestellt, und Sie führen df/du in einem Container aus, der Volumenhalterungen verwendet. Im Fall eines Verzeichnisses, das auf einem Volume auf dem Docker-Host bereitgestellt ist, meldet df die df-Summen des Hosts. Dies ist offensichtlich, wenn Sie darüber nachdenken, aber wenn Sie einen Bericht über einen "außer Kontrolle geratenen Container, der die Festplatte füllt!" Erhalten, stellen Sie sicher, dass Sie den Dateibereichsverbrauch des Containers mit etwas wie du -hs <dir> Überprüfen.

1
Troy Folger

In meinem Fall hat lsof nicht geholfen. Ich konnte dies aufspüren, weil ich Disk-Images mit losetup als Loop-Geräte gemountet hatte. Selbst nach dem Aushängen dieser Geräte und dem Löschen der entsprechenden Images gab es Prozesse, bei denen eine indirekte Referenz auf die Disk-Images beibehalten wurde.

Kurz gesagt, Sudo ps -ef|grep loop dann Sudo losetup -d /dev/loopX. Dies ist keine direkte Antwort darauf, warum du und df nicht übereinstimmen, aber es ist mir oft genug aufgetaucht, dass ich endlich herausfinden konnte, warum dies anders war als jede Antwort, die ich finden konnte.

0
ekeyser

Ich hatte das gleiche Problem, das in diesem Thema erwähnt wird, aber in einem VPS. Also habe ich alles getestet, was in diesem Thema beschrieben wird, aber ohne Erfolg. Die Lösung war ein Kontakt für die Unterstützung unseres VPS-Anbieters, der eine Neuberechnung des Kontingents durchführte und den Platzunterschied von df -h und du-sh /.

0
ldxd

Ich bin heute auf einer FreeBSD-Box auf dieses Problem gestoßen. Das Problem war, dass es sich um ein Artefakt von vi handelte (nicht vim, nicht sicher, ob vim dieses Problem verursachen würde). Die Datei verbrauchte Speicherplatz, war jedoch noch nicht vollständig auf die Festplatte geschrieben worden.

Sie können dies überprüfen mit:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Dies betrachtet alle geöffneten Dateien und sortiert (numerisch über -n) Nach der 8. Spalte (Schlüssel, -k8) Und zeigt die letzten zehn Elemente an.

In meinem Fall sah der letzte (größte) Eintrag folgendermaßen aus:

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

Dies bedeutete, dass der Prozess (PID) 12345 1,46 G (die achte Spalte geteilt durch 1024³) Festplatte verbrauchte, obwohl du dies nicht bemerkte. vi ist schrecklich beim Anzeigen extrem großer Dateien; sogar 100 MB sind groß dafür. 1,5 G (oder wie groß diese Datei tatsächlich war) ist lächerlich.

Die Lösung war Sudo kill -HUP 12345 (Wenn das nicht funktionieren würde, würde ich Sudo kill 12345 Und wenn das auch fehlschlägt, würde das gefürchtete kill -9 Ins Spiel kommen).

Vermeiden Sie Texteditoren für große Dateien. Beispielumgehungen zum schnellen Überfliegen:

Unter der Annahme angemessener Leitungslängen:

  • { 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 -

Angenommen, unangemessen große Zeile (n):

  • { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Diese verwenden vim -R Anstelle von view, da vim fast immer besser ist ... wenn es installiert ist. Fühlen Sie sich frei, sie stattdessen in view oder vi -R Zu leiten.

Wenn Sie eine so große Datei öffnen, um sie tatsächlich zu bearbeiten, ziehen Sie sed oder awk oder einen anderen programmatischen Ansatz in Betracht.

0
Adam Katz

überprüfen Sie, ob auf Ihrem Server ein Ossec-Agent installiert ist. Oder ein Prozess verwendet die gelöschten Protokolldateien. In meiner vor einiger Zeit war ossec Agent.

0
Richard Mérida

Ähnliches passierte uns in der Produktion, die Festplattennutzung stieg auf 98%. Hat folgende Untersuchung durchgeführt:

ein) df -i zur Überprüfung der Inode-Nutzung betrug die Inode-Nutzung 6%, also nicht viel kleinere Dateien

b) Mounten von root und Überprüfen versteckter Dateien. Es konnten keine extra Dateien abgelegt werden. du Ergebnisse waren die gleichen wie vor dem Mount.

c) Überprüfen Sie abschließend nginxlogs. Es wurde zum Schreiben auf die Festplatte konfiguriert, aber ein Entwickler löschte die Protokolldatei direkt, wodurch nginx alle Protokolle im Speicher behielt. Wie die Datei /var/log/nginx/access.log wurde mit rm von der Festplatte gelöscht. Mit du war es nicht sichtbar, aber auf die Datei wurde von nginx zugegriffen, und daher wurde sie immer noch gehalten open =

0
darxtrix

wenn es sich bei der bereitgestellten Festplatte um einen freigegebenen Ordner auf einem Windows-Computer handelt, zeigt df anscheinend die Größe und die Festplattennutzung der gesamten Windows-Festplatte an, aber du zeigt nur den Teil der Festplatte an, auf den Sie ebenfalls Zugriff haben. (und ist montiert). In diesem Fall muss das Problem auf dem Windows-Computer behoben werden.

0
Sverre