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.