Das Entfernen von Dateien dauert zu lange

Kurzversion : rm -rf mydirMit mydir(rekursiv) 2,5 Millionen Dateien dauert es auf einem meist inaktiven Computer ungefähr 12 Stunden.

Weitere Informationen : Die meisten Dateien, die gelöscht werden, sind feste Links zu Dateien in anderen Verzeichnissen (das zu löschende Verzeichnis ist tatsächlich die älteste Sicherung von rsnapshot; der rmBefehl wird tatsächlich von gegeben rsnapshot). Es werden also hauptsächlich Verzeichniseinträge gelöscht - der Dateiinhalt selbst ist nicht viel; es ist in der Größenordnung von einigen zehn GB.

Ich bin mir nicht sicher, ob btrfsdas der Schuldige ist. Ich erinnere btrfsmich, dass das Backup vor Beginn der Verwendung ebenfalls sehr langsam war , aber ich bin nicht sicher, ob die Langsamkeit beim Löschen lag.

Die Maschine ist ein Intel Core i5 2,67 GHz mit 4 GB RAM. Es hat zwei SATA-Festplatten: eine hat das Betriebssystem und einige andere Dinge, und die Sicherungsdiskette ist eine 1 TB WDC WD1002FAEX-00Z3A0. Das Motherboard ist ein Asus P7P55D.

Bearbeiten : Die Maschine ist ein Debian-Keuchen mit Linux 3.16.3-2~bpo70+1. So wird das Dateisystem gemountet:

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

Bearbeiten : Die Verwendung rsync -a --delete /some/empty/dir mydirdauert ca. 6 Stunden. Eine deutliche Verbesserung gegenüber rm -rf, aber immer noch zu viel, denke ich. ( Erklärung, warum rsyncschneller ist alsrm : "[M] ost-Dateisysteme speichern ihre Verzeichnisstrukturen in einem btree-Format. Die Reihenfolge [in], in der Sie Dateien löschen, ist ... wichtig. Sie müssen vermeiden, den btree beim Ausführen der Verknüpfung neu auszugleichen .... rsync -a --delete... löscht in der richtigen Reihenfolge ")

Bearbeiten : Ich habe eine andere Festplatte angehängt, die 2,2 Millionen Dateien (rekursiv) in einem Verzeichnis hatte, aber unter XFS. Hier einige Vergleichsergebnisse:

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] Mit hdparm -T /dev/sdXund hdparm -t /dev/sdX.
[2] Zeit, die find mydir -print|wc -lunmittelbar nach dem Start benötigt wird.
[3] Auf der XFS-Festplatte war dies kurz nach dem Gehen mit dem Baum find. Auf der BTRFS-Festplatte handelt es sich um die alte Messung (und ich glaube nicht, dass der Baum zwischengespeichert wurde).

Es scheint ein Problem mit zu sein btrfs.

linux btrfs

— Antonis Christofides
quelle

2,5 Millionen Dateien in einem einzigen Verzeichnis? Mir ist kein Dateisystem bekannt, das dies gut handhabt.

— Michael Hampton

@ MichaelHampton: Es ist nicht flach, es enthält verschachtelte Verzeichnisse. Ich habe das Wort "rekursiv" in die Kurzbeschreibung eingefügt. Ich hoffe das klärt es.

— Antonis Christofides

Warum verwenden Sie den Copy-on-Write-Verzeichnis-Trick in einem Copy-on-Write-Dateisystem?

— Symcbean

@symcbean: Du meinst, dass der Hardlink-Trick überflüssig ist btrfs? Dies ist natürlich möglich, aber denken Sie, dass es relevant sein könnte? Im Moment kann ich mich nicht erinnern, warum ich mich entschlossen habe, es zu versuchen btrfs.

— Antonis Christofides

Ah, ich erinnere mich jetzt. Ich habe mich für einen Wechsel entschieden, btrfsweil ich die transparente Komprimierung wollte. Jetzt: rsnapshotverwendet harte Links. Es gibt keine Option, keine festen Links zu verwenden. Die Hardlinks überschneiden sich also mit btrfsder Copy-on-Write-Funktionalität, aber ich kann nicht viel dagegen tun.

— Antonis Christofides

Antworten:

Nun, dies ist immer noch ein Btrfs-Problem. Es ist bekannt, dass das Löschen vieler kleiner Dateien im Vergleich zu anderen Dateisystemen ziemlich lange dauert.

Wenn Sie es nicht mögen, können Sie entweder warten, bis der Upstream es behoben hat, oder zu einem anderen Dateisystem wechseln, das es besser macht.

Ihr Hauptfehler ist jedoch die Verwendung eines alten Kernels (3.16, ja, es war bereits uralt, als Sie gepostet haben) mit btrfs. Btrfs ist ein Dateisystem, das sich noch in der Entwicklung befindet. Sie sollten daher immer bei der neuesten und besten Kernel-Version bleiben, um mit den Verbesserungen in Kontakt zu treten. Wenn Ihre Distribution keine Backports ausführt, können Sie dies entweder selbst tun oder Sie sind geschraubt.

Btrfs hat in Kernel-Version 3.19 viele Leistungsverbesserungen erzielt - dies ist die Mindestversion, die Sie in der Produktion verwenden sollten. Ihre Kernel-Version 3.16 ist ohne Backports einfach zum Kotzen.

Denken Sie auch daran, dass er laut Chris Mason Btrfs inzwischen als stabil, aber noch nicht produktionsbereit ansieht.

— Marc Stürmer
quelle

Wie definieren Sie "bekannt"? Ich hatte das Internet ausgiebig und vergeblich durchsucht, und niemand von denen, die an dieser Diskussion teilnahmen, wusste davon. Aber sowieso halte ich mich jetzt nur fern btrfs. Zu hochgespielt, während seine Entwicklung ewig zu dauern scheint.

— Antonis Christofides

Nun, es gibt zum Beispiel die Leute von CoreOS. Sie verwendeten ungefähr Btrfs ein Jahr als Standarddateisystem bis Anfang 2015, wo sie damals zu Ext4 + Overlayfs wechselten. Beachten Sie jedoch, dass dies vor der Kernel-Version 3.19 war, die viele Verbesserungen für Btrfs brachte. Schauen Sie sich auch diese Präsentation vom Oktober 2015 an, die sich mit ext4, xfs, zfs und btrfs zu den Bedingungen für die Datenbankauslastung befasst, nämlich Postgres: de.slideshare.net/fuzzycz/… Ein weiterer Benchmark, wenn auch nicht so guter Kernel: goo.gl/rR3kZ2

— Marc Stürmer

Und wie ich bereits sagte, ist bekannt, dass die Kernel-Version Ihrer Box (3.16) von Leistungsproblemen geplagt ist. Verwenden Sie laut Chris Mason zumindest 3.19 für ernsthafte Btrfs-Inhalte. Wenn Sie Btrfs ernsthaft verwenden möchten, verwenden Sie immer den neuesten und besten Kernel - etwas, das mit Debian nicht wirklich gut funktioniert ... und den Suchbegriff "btrfs-Metadatenleistung".

— Marc Stürmer

Ich bin ein bisschen zu spät zu dieser Party, aber hier ist ein Trick, um extrem große btrfs-Bäume sehr schnell zu löschen:

Erstellen Sie ein Dummy-Subvolume im selben btrfs-Dateisystem.
Verschieben Sie das Verzeichnis der obersten Ebene, das Sie entfernen möchten, in das Subvolume. Dieser Vorgang sollte sehr schnell sein, wenn Sie ihn auf demselben btrfs-Dateisystem ausführen, auch über Subvolumes hinweg.
Zerstöre das Subvolumen.

Der Kernel wird im Hintergrund Speicherplatz zurückfordern, sodass Sie nicht sofort über den verfügbaren Speicherplatz verfügen. Der Vorgang sollte jedoch viel schneller sein als das Löschen von Benutzerland.

— Nicolas Noble
quelle

Sie können das Verzeichnis umbenennen und dann das umbenannte Verzeichnis in einem Hintergrundprozess löschen. Dies wird den Löschvorgang nicht beschleunigen. Dies würde es dem Programm jedoch ermöglichen, mit einem leeren Verzeichnis fortzufahren, während der Löschvorgang auf der Seite ausgeführt wird.

Ich bin nicht sicher, ob dies in Ihrem Anwendungsfall funktionieren wird. Dies hängt davon ab, ob das Programm erst fortgesetzt werden kann, wenn sich die Festplatte im Leerlauf befindet (dh einige schwere Festplattenoperationen ausführen). Es hängt davon ab, ob das Programm die Festplatte mit vielen Daten füllen wird.

— Nathan
quelle