rzip64 DE
rzip64 ist ein schnelles, unterbrechbares und paralleles Programm zur Datenkompression von sehr großen Dateien.
Vorgängerversionen
Das Tool rzip64 basiert auf dem Programm rzip von Andrew Tridgell und Paul Russell, welches seinerseits auf der bzip2-Bibliothek aufsetzt.
Die wesentliche Verbesserung von rzip gegenüber bzip2 bestand darin, dass die Eingangsdaten in größeren Blöcken bearbeitet werden.
Hierdurch steigt der RAM-Bedarf erheblich an, aber gleichzeitig verbessert sich auch die Kompressionrate deutlich.
Dateien, die mit rzip gepackt wurden, sind daher in der Regel kleiner als bzip2-Dateien.
Unterbrechbarkeit
Leider dauert das Komprimieren mit rzip sehr lange. Bei sehr großen Dateien ist dies besonders hinderlich. Hier bringt rzip64 nun eine wesentliche Verbesserung.
Wie die meisten der gängigen Kompressionsprogramme bearbeitet auch rzip64 seine Eingangsdaten blockweise. Mit der Option -G kann jeder Block separat abgespeichert werden, sobald er fertig komprimiert ist. Falls nun rzip64 während der Arbeit unterbrochen wird, gehen die bereits fertigen Blöcke ("Slices") nicht verloren. Das Abspeichern der fertigen Slices geschieht dabei so, dass sich die Daten zu keinem Zeitpunkt in einem inkonsistenten Zustand befinden.
Das Unterbrechen von rzip64 geschieht über ein schlichtes
Über ein simples Startscript kann dann beim nächsten Booten das Komprimieren automatisch wieder angeworfen werden. rzip64 setzt die Kompression genau an der Stelle fort, wo es zuvor unterbrochen wurde.
Für Administratoren ergibt sich so die Möglichkeit, große Backup-Files (z. B. tar-Archive) im Hintergrund komprimieren zu lassen, ohne dass dies die normalen Wartungszyklen (Herunterfahren und/oder Neustarten des Systems, usw.) behindert. Ebenso wäre denkbar, die Kompression automatisch in den Nachtstunden zu starten und rzip64 jeweils morgens zu unterbrechen, wenn Mitarbeiter den betreffenden Rechner für andere Zwecke benötigen.
Zur Laufzeit benötigt rzip64 keinerlei Interaktion mit dem User. Bei ernsten Problemen (z. B. nicht ausreichendem Plattenplatz) bricht rzip64 ab, hinterläßt dabei aber die Originaldatei unangetastet (Wenn später wieder Plattenplatz zur Verfügung steht, kann man rzip64 in gewohnter Weise fortsetzen).
Parallelität
Das Slice-Konzept ermöglicht zudem eine elegante Erweiterung für Multicore-CPUs. Über einen zusätzlichen Parameter (-j) kann der Anwender die Zahl der CPU-Kerne festlegen, die gleichzeitig von rzip64 genutzt werden sollen.
Die Unterbrechbarkeit geht dabei nicht verloren, sondern sorgt sogar für eine gewisse Extra-Flexibilität: wenn man rzip64 unterbricht, dann kann man beim Neustart auch eine abweichende Kernzahl angeben und so rzip64 an die Rechenkapazität anpassen, die jeweils gerade zur Verfügung steht.
Die Skalierbarkeit von rzip64 ist relativ hoch, solange das darunter liegende Plattensystem schnell genug ist und die CPUs über ausreichend Speicher verfügen (optimal: 1 GByte pro CPU). Natürlich fühlt sich rzip64 auf Prozessoren mit großen Caches besonders wohl, weil sich die einzelnen Kerne dann weniger gegenseitig behindern. rzip64 läuft gut auf NUMA-Systemen, in denen die einzelnen CPUs ihren jeweiligen Arbeitsspeicher separat angebunden haben, weil die CPUs während der Datenkompression nicht miteinander kommunizieren müssen.
Plattenplatzbedarf
In ungünstigen Fällen benötigt der komprimierte Output von rzip64 etwa so viel Platz wie die Originaldatei. Im Dateisystem muß also genügend Platz frei sein, um gegen Ende der Kompression beide Dateien ablegen zu können. Erst wenn die Kompression erfolgreich abgeschlossen wurde, wird die Originaldatei entfernt.
Auch die Verwendung von Slices ändert daran nichts, beansprucht darüber hinaus aber kaum zusätzlichen Platz. Wenn am Ende die Slices zum endgültigen Outputfile zusammengefasst werden, werden die nicht mehr benötigten Slices sofort gelöscht, so dass der Platzbedarf in der abschließenden Merge-Phase nicht wesentlich ansteigt (ca. eine Slice-Größe).
Wenn zwischendurch zu wenig Plattenplatz zur Verfügung steht, bricht die Kompression mit einer Fehlermeldung ab. Die Originaldatei wird dabei nicht beschädigt. Sofern die Option -G benutzt wurde, kann man die Kompression später fortsetzen, sobald wieder Plattenplatz verfügbar ist.
Vergleichsmessungen
Für die folgenden Messungen wurde ein komplettes Backup eines Linux-System benutzt, das eine Größe von 103 GByte hatte. Das Testsystem war mit zwei Intel Xeons bestückt (E5430, 2.66 GHz, jeweils 4 Cores, kein Hyperthreading) und 16 GByte RAM. Es verfügt allerdings nur über eine einzelne Festplatte mit XFS-Dateisystem.
| Befehl | Laufzeit | Endgröße | Kompressionsrate |
| gzip -9 Bkp.tar | 4:25 Stunden | 64.151.681.574 Byte | 37,8 % |
| bzip2 -9 Bkp.tar | 10:07 Stunden | 62.024.265.251 Byte | 39,9 % |
| rzip64 -9 Bkp.tar | 14:03 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G Bkp.tar | 14:10 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j2 Bkp.tar | 8:27 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j3 Bkp.tar | 6:15 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j4 Bkp.tar | 5:26 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j5 Bkp.tar | 4:59 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j6 Bkp.tar | 4:48 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j7 Bkp.tar | 4:41 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j8 Bkp.tar | 4:38 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j9 Bkp.tar | 5:21 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j10 Bkp.tar | 5:44 Stunden | 55.002.636.998 Byte | 46,7 % |
| rzip64 -9 -G -j11 Bkp.tar | 6:04 Stunden | 55.002.636.998 Byte | 46,7 % |
Im Vergleich mit den beiden etablierten Werkzeugen schlägt sich rzip64 ganz ordentlich. Auch der zusätzliche Overhead für den Stop-and-Go-Mode bremst rzip64 nur unwesentlich.
Durch die Verteilung auf mehrere CPUs kann man die benötigte Kompressionszeit auf weniger als ein Drittel reduzieren. Je mehr CPUs sich allerdings die Arbeit teilen, desto mehr begrenzen andere Rechnerkomponenten den Geschwindigkeitsgewinn. An erster Stelle stehen dabei die Wartezeiten auf Festplattenzugriffe - ein schnelles Plattensystem (z. B. RAID) ist daher zu empfehlen.
Wie sehr das I/O Subsystem bereits am Anschlag ist, erkennt man gut an den letzten drei Zeilen, wo mehr parallele Prozesse gestartet werden, als CPUs verfügbar sind. Hier behindern sich die Prozesse gegenseitig erheblich (Benchmark details).
Abschließend noch ein Blick auf die Dekompressionszeiten:
| Befehl | Laufzeit | Endgröße | |
| gzip -d Bkp.gz | 0:18 Stunden | 103.214.827.520 Byte | |
| bzip2 -d Bkp.bz2 | 4:18 Stunden | 103.214.827.520 Byte | |
| rzip64 -d Bkp.rz | 3:17 Stunden | 103.214.827.520 Byte |
Beim Auspacken hängt gzip die Konkurrenz deutlich ab. Dafür ist andererseits das gzip-Archiv gute 9 GByte größer als das rzip64-Archiv.
Den Vergleich mit bzip2 gewinnt rzip64 klar. Der große Zeitunterschied erscheint auf den ersten Blick erstaunlich, weil rzip64 und bzip2 beide auf dem gleichen Grundalgorithmus basieren. Möglicherweise profitiert rzip64, das über größere Distanzen arbeitet, hier überproportional vom großen RAM der Testmaschine.
Open Source
rzip64 ist komplett samt Sourcecode verfügbar und steht unter der GNU General Public License in aktuellster Version. Obwohl wir rzip64 seit einiger Zeit erfolgreich im praktischen Betrieb benutzen, übernehmen wir keinerlei Garantien, welcher Art auch immer. Die Nutzung erfolgt also ausschließlich auf eigenes Risiko des Anwenders.
Kompatibilität
Dateien, die mit rzip64 gepackt wurden, sind voll kompatibel zu rzip und umgekehrt.
Im Vergleich zu gzip und bzip2 benötigt rzip64 mehr RAM. Dadurch kann es in ungünstigen Fällen vorkommen, dass sich ein komprimiertes File auf einer kleineren Maschine nicht mehr auspacken lässt. Solange man zu Auspacken den gleichen Rechner benutzt wie zum Packen, tritt dieser Effekt nicht auf.
Download
Hier gibt es rzip64 zum direkten Herunterladen: