☰

Riesiges Verzeichnis, nicht die darin enthaltenen Dateien, sondern das Verzeichnis selbst

tag-icon • tag-icon linux filesystems ext3
Riesiges Verzeichnis, nicht die darin enthaltenen Dateien, sondern das Verzeichnis selbst

Ich versuche rm -Rf /root/FFDCseit 15 Stunden, ein Verzeichnis von einem CentOS-Server zu löschen, und habe große Schwierigkeiten. Ich kann keine Verzeichnisliste erstellen, da das System dadurch hängen bleibt (zu viele Dateien?), aber ich sehe, dass die Verzeichnisgröße nicht die üblichen 4096 Bytes, sondern 488 MB beträgt!

[root@IS-11034 ~]# ls -al
total 11760008
drwxr-x--- 31 root root        4096 Aug 10 18:28 .
drwxr-xr-x 25 root root        4096 Aug 10 16:50 ..
drwxr-xr-x  2 root root   488701952 Aug 11 12:20 FFDC

Ich habe die Inodes überprüft und alles scheint in Ordnung zu sein. Ich habe top überprüft und rmdie CPU-Auslastung beträgt nach 15 Stunden immer noch 0,7 %. Dateisystemtyp ist ext3.

Ich weiß jetzt nicht, was ich außer einem Backup und Formatieren tun soll.

Antwort1

Ist das überhaupt ls -1f /root/FFDClangsam? Mit -1f wird die Ausgabe nicht sortiert und die Dateidetails werden weggelassen.

Wenn das obige ls schnell läuft, find /root/FFDC | xargs rm -vfwäre vielleicht etwas wie schneller? Ein Normal rm -rfkönnte alle möglichen Rekursionen ausführen, die er findVIELLEICHT überspringen könnte. Oder auch nicht.

Ist Ihr Dateisystem mitsynchronisierenOption? Wenn ja, dann ist die Schreib-/Löschleistung schrecklich langsamer, als sie mitasynchron. Im Zweifelsfall können Sie es versuchen mount -o remount,async /(oder mount -o remount,async /rootwenn es bei Ihnen ein separates Dateisystem ist).

Antwort2

Haben Sie in Betracht gezogen, das Dateisystem auszuhängen und dann e2fsck auszuführen, um das Dateisystem auf Fehler zu überprüfen? Ich würde dies vor dem Sichern, Formatieren und Wiederherstellen versuchen.

Antwort3

Das Ausführen von fsck auf dem Dateisystem behebt das Problem. Es tritt normalerweise auf, wenn ein Verzeichnis früher viele Dateien enthielt, dies jetzt aber nicht mehr der Fall ist. Die Verzeichnisgröße wird als riesige Zahl angegeben und die Leistung leidet.

Antwort4

Ich bin nicht sicher fsck(8), ob die Verzeichnisse neu organisiert werden. Sie können es mit dem -DFlag versuchen (wie in beschrieben e2fsck(8)). Wenn dies nicht der Fall ist und sich in diesem Verzeichnis wirklich nicht Millionen von Dateien befinden, können Sie mit etwas wie dem Folgenden ein Verzeichnis mit angemessener Größe erstellen:

cd /root mv FFDC FFCD-old mkdir FFCD # Passen Sie die Berechtigungen für FFDC an mv FFDC-old/* FFDC # Überprüfen/verschieben Sie alle .xxx-Dateien/Verzeichnisse in FFDC-old rmdir FFCD-old

Zumindest einige Bash-Versionen erhalten Globs wie .a[^.]*falsch und include .und ..trotzdem, sonst können Sie den vorletzten Schritt versuchen alsmv FFDC-old/.* FFDC

Dateisysteme wie ext3/ext4 behandeln Verzeichnisse im Wesentlichen als verknüpfte Listen nicht verschiebbarer Knoten mit Platz für Dateiname + Inode-Nummer. Wenn eine Datei nicht verknüpft wird, wird der Platz für den Namen freigegeben (und sollte mit freien Nachbareinträgen, falls vorhanden, zusammengeführt werden). Ein so riesiges Verzeichnis mit wenigen Dateiendürfenerstellt werden, aber es ist nicht einfach. Vielleicht Millionen von Hardlinks zu denselben wenigen Dateien erstellen? Millionen von Links mit sorgfältig ausgewählten Namen erstellen/löschen? Was auch immer passiert ist, um dies zu erstellen, sollte untersucht werden; ist es ein Streich, eine Art Fehlfunktion des Dateisystems, ...?

verwandte Informationen