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

[Andreas Jellinghaus]

Am Mittwoch, 24. September 2008 23:55:27 schrieb Armin Kunaschik:
> > Ein einfaches rm * scheidet also aus. In Internet wird die Lösung
> >
> > find . -type -f | xargs -n100 rm -f
>
> Bei dieser Loesung muss ich mal wieder etwas "klugscheissen":
> xargs "weiss" selber (auch unter Linux), wie lang eine Argumenten-
> Liste sein darf und wieviel Argumente dem rm uebergeben werden duerfen.
> Die oben beschriebene Loesung sollte sich also schon um einige
> ein- bis zweistellige Prozentzahlen tunen lassen, wenn man einfach
> das -n100 weglaesst.

Das kam mir seltsam vor. So viel unterschied? Ich habe mal gemessen:

Vorbereitung:
cd /tmp
mkdir x
cd x
let i=0; while let "i<100000"; do echo > `printf %06d $i`; let i="$i+1"; done
cd ..
tar cfz 100k.tar.gz x
rm -rf x

Test Verfahren 1
cd /tmp
tar xfz 100k.tar.gz
cd x
time (find . -type f|xargs -n100 rm -f)
cd ..
rmdir x

Test Verfahren 2
cd /tmp
tar xfz 100k.tar.gz
cd x
time (find . -type f|xargs rm -f)
cd ..
rmdir x

Test Verfahren 3
cd /tmp
tar xfz 100k.tar.gz
time (rm -rf x)

Getestet auf Ubuntu 8.04, x86_64, lenovo T61 laptop
(T7500 @ 2.2Ghz, 4GB Ram, ext3 data=ordered, ...)
[   25.369582] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   25.371633] ata1.00: ATA-7: WDC WD1600BEVS-08RST2, 08.01G08, max UDMA/133
[   25.371635] ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32)
[   25.371469] ata1.00: configured for UDMA/133


Ergebnisse
Test 1
real    0m14.428s		user    0m1.668s		sys     0m4.168s
real    0m11.316s		user    0m1.952s		sys     0m4.808s
real    0m16.188s		user    0m1.836s		sys     0m4.680s
real    0m15.320s		user    0m1.704s		sys     0m3.808s
real    0m15.883s		user    0m1.808s		sys     0m4.512s


Test 2
real    0m11.720s		user    0m0.112s		sys     0m1.824s
real    0m12.451s		user    0m0.112s		sys     0m2.152s
real    0m14.777s		user    0m0.164s		sys     0m2.832s
real    0m14.818s		user    0m0.212s		sys     0m3.032s
real    0m16.457s		user    0m0.108s		sys     0m1.968s


Test 3
real    0m9.494s		user    0m0.032s		sys     0m2.532s
real    0m11.044s		user    0m0.028s		sys     0m2.656s
real    0m16.114s		user    0m0.032s		sys     0m3.012s
real    0m15.686s		user    0m0.056s		sys     0m2.992s
real    0m15.075s		user    0m0.084s		sys     0m3.272s

Durchschnitt
Test 1	real	14.627		user	1.793			sys	4.395
Test 2	real	14.044		user	0.141			sys	2.361
Test 3	real	13.482		user	0.056			sys	2.892

In Prozent (Test1=100%)
Test 1	real	100		user	100			sys	100
Test 2	real	96		user	7.8			sys	53.7
Test 3 	real	92.1		user	3.1			sys	65.8

Sind 4% Unterschied nun "einige ein- bis zweistellige Prozentzahlen"? Möge 
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".

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.

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.

Mit freundlichen Grüßen

Andreas Jellinghaus