Frage Das Ausführen eines rm -rf in einem riesigen Verzeichnisbaum dauert Stunden


Wir verwenden rsnapshot für Backups. Es speichert viele Snapshots der gesicherten Datei, löscht jedoch alte. Das ist gut. Es dauert jedoch ungefähr 7 Stunden, um ein zu tun rm -rf in einem massiven Verzeichnisbaum. Das Dateisystem ist XFS. Ich bin mir nicht sicher, wie viele Dateien da sind, aber es sind wahrscheinlich Millionen.

Gibt es trotzdem etwas, um es zu beschleunigen? Gibt es einen Befehl, der das Gleiche tut? rm -rf und braucht nicht Stunden und Stunden?


19
2017-07-28 08:26


Ursprung


ich benutzte find . -delete -name directory und es ist viel schneller als rm -rf. - Paolo


Antworten:


Nein.

rm -rf macht eine rekursive Tiefen-First-Traversierung Ihres Dateisystems, Aufruf unlink() auf jeder Datei. Die beiden Vorgänge, die den Prozess langsam ausführen, sind opendir()/readdir() und unlink(). opendir() und readdir() sind abhängig von der Anzahl der Dateien im Verzeichnis. unlink() hängt von der Größe der zu löschenden Datei ab. Die einzige Möglichkeit, dies schneller zu machen, besteht darin, entweder die Größe und Anzahl der Dateien zu reduzieren (was vermutlich nicht wahrscheinlich ist) oder das Dateisystem auf eines mit besseren Eigenschaften für diese Operationen zu setzen. Ich glaube, dass XFS ist gut für unlink () auf große Datei, ist aber nicht so gut für große Verzeichnisstrukturen. Sie könnten feststellen, dass ext3 + dirindex oder reiserfs schneller ist. Ich bin mir nicht sicher, wie gut JFS läuft, aber ich bin mir sicher, dass es viele Benchmarks für die Leistung verschiedener Dateisysteme gibt.

Edit: Es scheint, dass XFS ist schrecklich beim Löschen von BäumenÄndere dein Dateisystem definitiv.


38
2017-07-28 08:41



Vor einigen Jahren habe ich in einem ähnlichen Anwendungsfall schreckliche Leistung mit Reiserfs festgestellt. - knweiss
Wunderbarer Beitrag! - wzzrd
Es sagte fast nur "Nein" :) - David Pashley
Ich stimme allem hier zu, abgesehen von Ihrer Aussage, dass die Verbindungsgeschwindigkeit abhängig von der Größe der Datei ist. unlink entfernt nur den Link zu der Datei und ändert nichts am Inhalt. Es sollte keinen erkennbaren Unterschied zwischen Dateien unterschiedlicher Größe geben (Sie können dies selbst testen). - Kamil Kisiel
@KamilKisiel Du sagst es richtig unlink tut nichts, um den eigentlichen Inhalt aber auszuführen unlink Systemaufruf hat der Dateisystemcode jedoch mehr zu tun, wenn der entfernte Link der letzte zur Datei ist und wenn er gerade nicht geöffnet ist. Dies ist natürlich Dateisystem abhängig, aber es kann dann einen sehr erkennbaren Unterschied geben, wenn die entfernte Datei sehr groß ist. - jlliagre


Alternativ können Sie das Verzeichnis zur Seite verschieben, es mit demselben Namen, denselben Berechtigungen und demselben Besitz neu erstellen und alle Apps / Dienste neu starten, die sich um dieses Verzeichnis kümmern.

Sie können dann das ursprüngliche Verzeichnis im Hintergrund "nice rm" machen, ohne sich um einen längeren Ausfall kümmern zu müssen.


22
2017-07-28 08:45



Das könnte funktionieren, da ein MV sehr sehr schnell ist. - Rory
Yup - es funktioniert gut. Ich habe diese Technik viele Male benutzt, um Maildir-basierte Mailboxen zu "reparieren", bei denen ein E-Mail-Client sein Gehirn verloren hat und auf der Festplatte ein Durcheinander hinterlassen hat. Das größte (einzige) Verzeichnis, das ich auf diese Art und Weise repariert habe, hat ungefähr 1,5 oder 2 Millionen Dateien IIRC. Die gesamte Ausfallzeit für den Endbenutzer betrug ~ 3 Minuten, von denen die meisten darauf warteten, dass der E-Mail-Client und die IMAP-Prozesse abstarben. - Greg Work


Stellen Sie sicher, dass Sie die richtigen Mount-Optionen für XFS festgelegt haben.

Wenn Sie -ologbufs = 8, logsize = 256k mit XFS verwenden, wird Ihre Löschleistung wahrscheinlich verdreifacht.


7
2017-09-21 20:52



+1 für diesen Tipp ... Man sollte Lazy Counter auch für einen weiteren Leistungsschub aktivieren. - hurikhan77
Einige Erklärungen zu diesen Einstellungen wären für zukünftige Leser hilfreich. - Aron Rotteveel


Wenn Sie das RM effektiv auf Dateiebene ausführen, wird es lange dauern. Deshalb sind blockbasierte Snapshots so gut :).

Du könntest versuchen, das RM in getrennte Bereiche aufzuteilen und es parallel zu tun, aber ich erwarte nicht, dass es Verbesserungen bringt. Es ist bekannt, dass XFS Probleme beim Löschen von Dateien hat und wenn das ein großer Teil von dem ist, was Sie tun, dann wäre vielleicht ein anderes Dateisystem dafür eine Idee.


5
2017-07-28 08:36



Blockbasierte Snapshots sind in diesem Fall nicht eindeutig gut. Eine Reihe von Dateisystemen --- WAFL und ZFS kommen mir sofort in den Sinn --- bieten auch eine gute Leistung für das Löschen von Schnappschüssen. Sie behandeln Snapshots als erstklassige Dateisystemobjekte. Anstatt also (langsam) über Millionen von Dateien zu iterieren, um festzustellen, welche Blöcke freigegeben werden sollen, müssen sie nur die Blockliste anzeigen, die dem Snapshot zugeordnet ist. - Keith Smith
Hmm. Ich bin wahrscheinlich davon ausgegangen, dass es oben zu konträr ist. Das Original-Poster muss Linux benutzen, und es gibt wirklich kein bewährtes Linux-Dateisystem, das Schnappschüsse macht - obwohl Btrfs und Nilfs für die Zukunft interessant aussehen. Aus praktischen Gründen stimme ich zu - besser, blockbasierte Snapshots zu verwenden. - Keith Smith
+1, damit der Tipp die Arbeitslast teilt und parallelisiert: xfs spielt seine Stärke auf parallelen Arbeitslasten. - hurikhan77


Es ist gut, ionice für IO-intensive Operationen unabhängig vom verwendeten Dateisystem zu verwenden.
Ich schlage diesen Befehl vor:

ionice -n7 nice rm -fr dir_name

Es wird gut für Hintergrundoperationen auf Servern mit hoher IO-Belastung spielen.


5
2017-08-19 15:02





Ich weiß, das ist alt, aber ich dachte, ich könnte einen Vorschlag machen. Sie löschen diese Dateien sequenziell. Das Ausführen von parallelen rm-Vorgängen könnte die Vorgänge beschleunigen.

http://savannah.nongnu.org/projects/parallel/ Parallel kann anstelle von Xargs verwendet werden

Also, wenn Sie alle Dateien in Deltedir löschen

find -t f deletedir | parallel -j 10 rm

Das würde nur leere Verzeichnisstrukturen zum Löschen übrig lassen.

Hinweis: Sie werden wahrscheinlich immer noch die Dateisystembeschränkungen treffen, wie oben erwähnt.


2
2018-01-28 21:31



Was ist der Vorteil von Parallel-über-Xargs? - Rory


Wäre eine alternative Option hier, die Daten so zu trennen, dass Sie das eigentliche Dateisystem junkern und neu aufbauen können anstatt das rm zu tun?


1
2017-07-28 08:50



Ich denke, rsnapshot verwendet Hard-Links als Teil der Funktion "Pflege mehrerer Snapshots - effizient". Also, wenn der Fragesteller dieses Feature mit separaten Dateisystemen verwendet, wird es nicht funktionieren (da Sie nicht über eine Dateisystemgrenze fest verknüpfen können) - David Spillett


Wie wäre es mit der Verringerung der Nettigkeit des Befehls? Mögen:

nice -20 rm -rf /path/to/dir/

0
2017-07-28 08:38



Der Engpass ist nicht der Scheduler, sondern das Dateisystem, würde ich sagen. - Manuel Faux
In dem unwahrscheinlichen Fall, dass der Scheduler der Engpass ist, würden Sie das E / A-Subsystem nur noch härter schlagen, wodurch der Server während des RMs noch unbrauchbarer wird. - David Mackintosh