~dhe

Wer stand nicht schon einmal vor dem Problem viele Dateien kopieren zu müssen? Sei es zum Austausch von Festplatten oder zu anderweitigen Arbeiten.

Nachdem ich das letzte mal mit einem befreundeten Arbeitskollegen 2h in einem Frankfurter Mac Donalds um die Ohren gehauen habe (um 3 Uhr Nachts), während ein Linux Server ca. 30GB IMAP Ordner und E-Mails kopiert, habe ich mir gedacht es muss einen besseren (schnelleren) Weg geben.
Und je nachdem wie man dieses Thema bisher angeht gibt es den auch, soviel sei schon mal vorab verraten.

Das Testsystem sieht wie folgt aus:
- Debian Etch
- 250 GB Maxtor Festplatte
- 2 mal Intel Xeon CPU 3.00GHz
- tar, rsync und cp aus den Debian Packages

Verglichen wird die Performance von:
- tar
- rsync
- cp

Szenario 1 – Kernelarchiv:

Anlegen der Ordnerstrukturen:

mkdir -p /test3/cp
mkdir /test3/tar
mkdir /test3/rsync
 
mkdir /root/test3
cd /root/test3
wget ftp://ftp.probe-networks.lkams.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.4.tar.bz2
tar xfj linux-2.6.24.4.tar.bz2

Dateianzahl und Größe:

find /root/test3 -type f | wc -l
23064
 
du -h -s /root/test3
349M    /root/test3

Unter /test3 werden die Programme die kopierten Daten ablegen. /root/test3 ist das Quellverzeichnis. Beide Verzeichnisse befinden sich auf der selben o.g. Disk und in einer ext3 Partition.

Ergebnisse:

time ( cp -Rp /root/test3 /test3/cp )
real 0m23.684s
user 0m0.345s
sys 0m3.761s

time ( cd /root/test3 && tar -cp -f – . | ( cd /test3/tar && tar -xp -f – ) )
real 0m12.009s
user 0m0.589s
sys 0m3.731s

time ( rsync -avz /root/test3 /test3/rsync/ > /dev/null )
real 0m24.715s
user 0m26.811s
sys 0m4.469s

Wie unschwer zu erkennen ist, hat die “doppelte” tar Lösung hier die Nase vorne.

Szenario 2 – 100 Verzeichnisse mit je 10 100k großen Dateien:

Vorbereitung – Anlegen der Testumgebung:

mkdir -p /test/cp
mkdir /test/tar
mkdir /test/rsync
mkdir /root/test
cd /root/test
 
for i in `seq 1 100`; do
 mkdir -p files-$i;
 for j in `seq 1 10`; do
  dd if=/dev/zero of=files-$i/$j bs=100k count=1 2> /dev/null;
 done;
done

Dateianzahl und Größe:

find /root/test -type f | wc -l
1000
 
du -h -s /root/test
102M    /root/test

Ergebnisse:

time ( cp -Rp /root/test /test/cp )
real 0m1.245s
user 0m0.032s
sys 0m0.481s

time ( cd /root/test && tar -cp -f – . | ( cd /test/tar && tar -xp -f – ) )
real 0m1.141s
user 0m0.066s
sys 0m0.799s

time ( rsync -avz /root/test /test/rsync/ > /dev/null )
real 0m2.669s
user 0m3.562s
sys 0m0.708s

Zwar nur hauchdünn, aber wieder gewinnt tar.

Szenario 3 – 1000 Verzeichnisse mit je 100 1k großen Files:

Vorbereitung – Anlegen der Testumgebung:

mkdir -p /test2/cp
mkdir /test2/tar
mkdir /test2/rsync
 
mkdir /root/test2
cd /root/test2
for i in `seq 1 1000`; do
 mkdir -p files-$i;
 for j in `seq 1 100`; do
  dd if=/dev/zero of=files-$i/$j bs=1k count=1 2> /dev/null;
 done;
done

Dateianzahl und Größe:

find /root/test2 -type f | wc -l
100000
 
du -h -s /root/test2
395M    /root/test2

Ergebnisse:

time ( cp -Rp /root/test2 /test2/cp )
real 1m0.924s
user 0m1.446s
sys 0m12.468s

time ( cd /root/test2 && tar -cp -f – . | ( cd /test2/tar && tar -xp -f – ) )
real 0m17.079s
user 0m1.758s
sys 0m6.880s

time ( rsync -avz /root/test2 /test2/rsync/ > /dev/null )
real 0m14.955s
user 0m10.187s
sys 0m15.202s

Hier gewinnt rsync knapp vor tar.

Interessantes:
Je öfter man diesen Test wiederholt umso schneller wird “cp”.
Die Geschwindigkeiten von rsync und tar bleiben bei Wiederholung nahezu gleich.

Hier die Werte vom 2ten und 3ten Versuch mit “cp” die direkt hintereinander stattgefunden haben:

real 0m37.064s
user 0m1.382s
sys 0m9.764s

real 0m15.462s
user 0m1.283s
sys 0m8.414s

Die Essenz die ich aus diesen Tests ziehe ist, dass “tar” die beste Allround Lösung beim kopieren von vielen kleinen oder großen Dateien zu sein scheint.
Vor allem bei Dateien die sich in keinem Cache des Systems befinden (z.B. sehr alte Backups o.Ä.) kopiert tar schneller als die anderen beiden Tools.

Warum tar teilweise 4 mal schneller als cp kopiert, welches nur für diesen zweck programmiert wurde und warum cp mit jedem neuen Anlauf immer schneller wird, sind 2 Dinge die es noch zu klären gilt.