[SAGE-MUC] Löschen von vielen (!) Files

[Armin Kunaschik]

Andreas Jellinghaus wrote:
> 
> Das kam mir seltsam vor. So viel unterschied? Ich habe mal gemessen:
> 
Ein klein wenig hatte ich sowas erwartet :-)

<snip>

> Sind 4% Unterschied nun "einige ein- bis zweistellige Prozentzahlen"? Möge 
Eindeutig ja. Auch wenn zweistellig fuer diese Hardware/Konfiguration wohl etwas
hoch gegriffen war, bleibt doch der Unterschied.

> doch bitte jeder selbst entscheiden. Natürlich lässt sich die Messgenauigkeit 
> verbessern, wenn man z.B. mit sync das journal vor dem löschen wegschreibt, 
> wenn man den ram des Rechners leert (reboot oder kernel entsprechend 
> anweisen). Vor allem auch mehr tests, 5 Tests sind nun nicht soo 
> aussagekräftig. Natürlich mehr Dateien, es hies im orginal
> Posting ja "> 100000".
Vielleicht sollten wir vorher doch mal eine Test-Umgebung definieren? :-)
Wie gross sind die Files? Wie lang die Dateinamen? Und die Mount-Optionen?
Ist ein "rm -rf x" ein gueltiger Beitrag? Es hiess ja "alle Dateien aus einem
Verzeichnis", nicht "ein Verzeichnis mit vielen Dateien".

> Am wichtigsten scheint mir aber, das die hier verwendeten Dateien mit einem 
> Byte unverhältnismässig klein sind. Größere Dateien zu löschen verbraucht 
> mehr Arbeit, weil mehr Datenstrukturen des Filesystems berührt werden. Solche 
> mehr Arbeit wird aber vorraussichtlich in alle Test Scenarien gleichermassen 
> eingehen. Die Unterschiede zwischen den verschiedenen Methoden werden dann 
> eher geringer, als stärker ausgeprägt.
Bei dieser Hardware-Konfiguration und den Datei-Groessen wird der meiste I/O
komplett im Buffer-Cache ablaufen. Das wird sich erst signifikant aendern, wenn
indirekte Bloecke ins Spiel kommen. Aber Du hast sicher Recht, es wird sich
auf alle Methoden gleich auswirken.

> Ich komme daher zum Schluss, das durch ein verschiedene Löschbefehle nur bis 
> zu 5 Prozent Unterschied feststellbar sind, in einem realistischeren Scenario 
> wohl eher 1-2 Prozenz, wenn überhaupt. Ein Tuning um "einige ein- bis 
> zweistellige Prozentzahlen" kann ich damit nicht nachvollziehen.
Effektiv wird ja auch nicht die Performance von rm ermittelt sondern der Overhead
von xargs. Ein fork (oder vfork) kostet halt auch heute noch messbare Zeit.
Die Unterschiede waren "damals" sicher groesser als heute, aber sie sind immer
noch da. Vielleicht haette ich besser "im unteren Prozentbereich" schreiben sollen,
denn ich habe sicherlich keine 20% oder 50% erwartet... da kam dann halt wieder
der Ingenieur in mir hoch, man schaetzt halt manchmal etwas zu optimistisch :-)

Interessant zu erwaehnen sollte hier auch sein, dass sich die Laufzeit der find-
Varianten verlaengern duerfte, wenn die Dateinamen laenger werden.
Bei einem ARG_MAX von 131072 (Linux) passen 18432 Dateinamen (6 Zeichen + 1 Leerzeichen)
in eine Argument-Liste. D.h. es werden gerade mal 6 rm-Befehle generiert.
Die -n100-Variante generiert unabhaengig von der Laenge des Dateinamens 1000 Aufrufe a
100 Argumente, wird aber bei Dateinamen (evtl. inkl. Pfad) von mehr als 131-Zeichen
ebenfalls mit "argument list too long" abbrechen.
Ein wenig Google bringt dann auch die passende Website zu ARG_MAX:
http://www.in-ulm.de/~mascheck/various/argmax/
Interessant hier ist, dass ab Linux 2.6.23 (also auch Ubuntu 8.04) gar kein Limit mehr
existieren duerfte. Wer testet das? Ich habe gerade kein entsprechendes Linux zur Hand...

Fakt ist, und das ist jetzt wieder Klugscheisserei, das der Parameter -n100
hier sinnlos ist. Und je aelter die Hardware ist (ok, das war keine Anforderung)
umso mehr wird der fork-Anteil mit in die Rechnung eingehen. Es gibt auch immer
noch UNIX-Versionen in Betrieb, deren ARG_MAX kleiner oder groesser im Vergleich zu
anderen ist (siehe Link), es daher durchaus sinnvoll ist, mit -n (wie generell
mit allen Ressourcen) sparsam umzugehen.

Ciao,
Armin