rm -r auf btrfs laaaangsam

[Christobal Zimmermann]

Guten Tag, liebe Leute!

Vor einiger Zeit habe ich eine neue Festplatte für Backups eingeweiht -
die alte war kaputt. :-P Wir haben für die Tage Mo-Fr jeweile eine
Platte. Das Backup-Skript macht aus jedem Verzeichnis ein tar.zstd
Archiv und packt das auf die eingelegte Platte. Die Platten sind direkt
per SATA angeschlossen (nicht über USB) durch einen Wechselrahmen.

Die neue Platte ist eine 12TB Toshiba Enterprise Capacity und relativ
voll. Ich musste also ein altes Backup löschen, damit ein neues drauf
passt. Normalerweise macht das Skript das automatisch, aber ich wollte
das älteste Backup erhalten, also habe ich eines "in der Mitte"
gelöscht.

Mir ist aufgefallen, dass das Löschen per rm -rv fast schon
unmenschlich lange gedauert hat:

real 3m22.885s
user 0m0.005s
sys 0m5.322s

Die gelösche Datenmenge beträgt ~1TB (etwas mehr), aber die Menge ist
aufgeteilt auf 133 Dateien und Verzeichnisse - für btrfs also
keinesfalls eine spektakuläre Menge, sollte man meinen.

Ich habe heute die "Gegenprobe" mit der Montagsplatte gemacht (die auch
schon recht voll ist). Diese Platte ist eine ST8000AS0002-1NA17Z, also
eine aus der Archive-Reihe mit SMR. Auf dem Papier müsste sie also
deutlich langsamer sein als die Toshiba. Doch das Löschen geht deutlich
zackiger von der Hand:

real 0m22.661s
user 0m0.000s
sys 0m0.477s

Auf der Montagsplatte ist ext4 statt btrfs.

Auf dem Fileserver läuft eine Suse Leap 15.5 - so halbwegs aktuell. :-)

Kann mir das jemand erklären? Ist btrfs doch noch nicht bereit für den
Produktiveinsatz?

Beste Grüße!
Chris

[Stefan Ram]

Post by Christobal Zimmermann
Guten Tag, liebe Leute!

Mhh, ich hoffe mal, daß "Subject:"-Zeilen von meinem Newsreader
nicht ausgeführt werden! ;-)

Also, ich habe keine Idee, woran es liegt, möchte aber anmerken, daß
man unter Linux mit Werkzeugen wie "iostat", "iotop", "sar", oder
"vmstat" etwas mehr über die Festplattenaktivität erfahren könnte.

Es dürfte zwar einen Unterschied in der Geschwindigkeit zwischen
BTRFS und EXT4 geben, aber dieser sollte normalerweise nicht
so ausgeprägt sein. Aber vielleicht ist das Löschen gerade
eine Ausnahme.

[Stefan Ram]

Post by Stefan Ram
Es dürfte zwar einen Unterschied in der Geschwindigkeit zwischen
BTRFS und EXT4 geben, aber dieser sollte normalerweise nicht
so ausgeprägt sein. Aber vielleicht ist das Löschen gerade
eine Ausnahme.

Hier verschiedene einschlägige Webseiten:

|Btrfs: Extremely slow delete of files - openSUSE Forums
|Is btrfs still super slow at deleting large files? It can take multiple seconds
|slow deletion of files - linux-***@vger.kernel.org
|Deleting containers is slow when using the btrfs storage driver #42973
|What is the fastest way to remove thousands of files on a btrfs ...
|Executing rm from ssh running *really* slow - Synology Community
|Btrfs Can Now Remove Directories Much Faster In Send Mode - Phoronix

. Wenn ich es richtig verstehe, wird das Problem in der ersten
Seite mit dem COW (copy on write) in Verbindung gebracht.

[Thomas Zajic]

Post by Christobal Zimmermann
[...]
Mir ist aufgefallen, dass das Löschen per rm -rv fast schon
real 3m22.885s
user 0m0.005s
sys 0m5.322s

vs.

Post by Christobal Zimmermann
[...]
real 0m22.661s
user 0m0.000s
sys 0m0.477s

Ist auditd aktiv? Gehts wieder normal schnell wenn du den auditd mal
kurz stoppst? Hatten wir letztens mal mit einigen SLES15 SAP Kisten
und den exakt gleichen Symptomen (das SAP Team war etwas verwundert,
warum das Auspacken von einem paar 100 MB großen Tarball nach einer
Stunde noch immer nicht fertig war :-D), da waren dann letztendlich
ein paar "gut gemeinte" auditd Rules schuld. ;-)

HTH
Thomas

[Christobal Zimmermann]

On Tue, 27 Aug 2024 10:08:58 +0200
Thomas Zajic <***@gmx.at> wrote:

Moin!

Post by Thomas Zajic
Ist auditd aktiv? Gehts wieder normal schnell wenn du den auditd mal
kurz stoppst? Hatten wir letztens mal mit einigen SLES15 SAP Kisten
und den exakt gleichen Symptomen (das SAP Team war etwas verwundert,
warum das Auspacken von einem paar 100 MB großen Tarball nach einer
Stunde noch immer nicht fertig war :-D), da waren dann letztendlich
ein paar "gut gemeinte" auditd Rules schuld. ;-)

That is very interesting! :-)

Ich hatte keine Ahnung, dass dieser auditd überhaupt existiert. Aber er
lief. Ich habe ihn mal deaktiviert, weil ich wüsste tatsächlich nicht,
wofür wir ihn brauchen.

Ich melde mich am Freitag mal, wenn ich wieder ein altes Backup lösche,
ob das etwas gebracht hat. ;-)

Beste Grüße!
Chris