XZ in BZ2 umwandeln

Eine SPS in einer Fertigungslinie, ein Embedded-Linux auf einer Maschine, die seit zwölf Jahren läuft und deren Firmware-Update-Fenster genau einmal im Jahr geöffnet wird — solche Geräte laufen mit einem Bruchteil des Arbeitsspeichers, den ein gewöhnlicher PC hat, und ihr Entpacker verlangt genau den Puffer, den xz zum Entpacken braucht.

Dasselbe Problem taucht bei einer Fritzbox mit alternativer Firmware oder einem OpenWrt-Router auf, dessen Flash-Speicher schon für das Firmware-Image knapp bemessen ist. In beiden Fällen ist die Frage nicht, welches Format besser komprimiert, sondern welches auf dem Gerät überhaupt entpackt.

Das Entpacken von XZ braucht einen Puffer, der auf das Wörterbuch der Datei skaliert — die Registry verzeichnet dafür 8 MB bei der Standardstufe, mit der die meisten xz-Archive entstehen. Auf einem normalen Rechner fällt das nicht auf. Auf einer Steuerung mit knapp bemessenem RAM, in einem speicherbegrenzten Container oder auf einer alten Unix-Maschine, deren Prozesslimit seit Jahren nicht angerührt wurde, ist genau das der Unterschied zwischen einem Archiv, das aufgeht, und einem Entpacker, der abgebrochen wird oder eine Speicherfehlermeldung zurückgibt.

Die zweite Version desselben Problems: xz ist auf dem Gerät schlicht nicht installiert. Das Format kam 2009, was für ein langlebiges Industriegerät jung genug ist, dass an Bord nur gzip und bzip2 stehen. Ein Binary nachzurüsten, ist bei einer zertifizierten Maschinensteuerung oft technisch oder organisatorisch gar nicht vorgesehen. Das Archiv umzuwandeln ist der Schritt, der tatsächlich erlaubt ist.

XZ setzt seit 2009 auf LZMA2, einen gleitenden Kompressor mit einem Wörterbuch von 8 MB in der Standardstufe, mit der die meisten xz-Archive geschrieben werden. Beim Komprimieren von Byte fünfzig Millionen kann er noch auf Byte zweiundvierzig Millionen zurückblicken, deshalb erkennt er Ähnlichkeiten über einen beträchtlichen Abschnitt eines Archivs hinweg. Zum Entpacken braucht die Gegenseite genau dasselbe Fenster im Speicher, weil ein Rückverweis überall darin liegen kann.

Bzip2 aus dem Jahr 1996 gleitet gar nicht. Es zerlegt die Eingabe in Blöcke von bis zu 900 KB, sortiert jeden mit einer Burrows-Wheeler-Transformation und codiert das Ergebnis. Ein Block steht für sich, der Entpacker hält also nie mehr als einen Block im Speicher. Genau diese Entscheidung kostet bzip2 die Kompressionsrate — es sieht nie weiter als 900 KB — und genau dieselbe Entscheidung macht es billig zu entpacken.

Der Größenunterschied ist real und schwankt stark mit dem Inhalt. Bei Quellcode, Log-Dateien oder Dokumentensammlungen mit viel Wiederholung über die ganze Sammlung hinweg hat XZ deutlich mehr gefunden, als bzip2 finden kann, und die BZ2-Datei fällt sichtbar größer aus.

Bei anderen Archiven verschwindet der Unterschied fast. Enthält das XZ Bilder, Video, Audio oder einen bereits komprimierten Datenbank-Dump, hatte der starke Kompressor nie viel zu finden, beide Formate verpacken die Daten im Grunde nur, und die beiden Ergebnisse liegen wenige Prozent auseinander. Ein Blick auf beide Zahlen lohnt sich, bevor irgendetwas Nachgelagertes darauf aufbaut — hier schwankt das Ergebnis leicht um eine ganze Größenordnung von einem Archiv zum nächsten.

Die Annahme, das schwächere Format sei überall schneller, stimmt nicht. XZ ist langsam beim Komprimieren, weil das Durchsuchen eines mehrere Megabyte großen Wörterbuchs aufwendig ist, aber vergleichsweise flott beim Entpacken, weil ein Rückverweis kaum mehr als ein Speicherkopiervorgang ist. Bzip2 verhält sich umgekehrt, und zwar auf eine Weise, die zählt: eine Burrows-Wheeler-Transformation rückgängig zu machen, ist echte Rechenarbeit, das Entpacken dauert entsprechend länger.

Das lohnt sich einzuplanen, denn es untergräbt teilweise den Grund für die Umwandlung. Die Steuerung braucht jetzt weniger Speicher, dafür mehr Zeit — und ist sie auch noch langsam getaktet, wie kleine Geräte es meist sind, kann das Entpacken deutlich länger dauern, als das XZ gebraucht hätte. Speicher ist die Grenze, die einen Auftrag unmöglich macht; Zeit ist die, die ihn nur lästig macht. Umgewandelt wird, wenn das Erste zutrifft, und die zweite Zahl wird vorher gemessen, bevor jemandem ein Zeitfenster versprochen wird.

Beide Formate komprimieren nur einen einzigen Datenstrom und wissen nichts von Dateien. Die Registry führt das Fehlen einer Verzeichnisstruktur für beide als bekannte Eigenschaft, weshalb beide fast immer mit einem TAR darin auftauchen. Diese Umwandlung packt das TAR aus dem XZ aus und schreibt es neu, bevor bzip2 komprimiert.

Keines der beiden Formate merkt sich einen ursprünglichen Dateinamen — anders als gzip — die Dateiendung ist also das Einzige, was die Datei später noch trägt. .tar.bz2 ist die richtige Wahl dafür. Dieselbe fehlende Namensangabe hat hier früher zu einem echten Fehler geführt, weil der innere Tar-Archivtyp erraten wurde, statt fest vorgegeben zu sein; heute wird der Tar-Typ erzwungen, statt aus einem beliebigen Zwischennamen geraten zu werden.

Der begrenzte Speicherbedarf steht im Vordergrund, aber es gibt einen zweiten Vorteil, der zum selben Publikum passt. Weil bzip2 seine Blöcke unabhängig voneinander komprimiert, geht bei einer beschädigten Datei nicht zwangsläufig alles nach der Beschädigung verloren — Wiederherstellungswerkzeuge finden die Blockgrenzen und retten, was intakt ist. Ein abgebrochener oder beschädigter xz-Datenstrom endet dagegen meist genau dort.

Das passt zu Umgebungen, in denen Flash-Speicher von unsicherer Qualität ist, Strom ohne Vorwarnung ausfällt und selten eine zweite Kopie in der Nähe liegt. Eine Backup-Strategie ist das nicht, und so sollte es auch nicht verkauft werden: Das TAR darin ist ein durchgehender Datenstrom, ein Teilerfolg beim Wiederherstellen ergibt also ein Tar mit Lücken, und was am Ende herauskommt, hängt davon ab, wo der Schaden lag. Es ist schlicht der bessere Ausfall als die Alternative.

Liegt der Grund für den Wechsel bei Speicher oder einem fehlenden Programm, löst gzip beides mindestens ebenso gut und kostet dabei weniger Zeit. Es braucht ein Fenster von 32 KB — praktisch nichts —, es ist auf so gut wie jedem System vorhanden, das überhaupt einen Kompressor mitbringt, und es entpackt auf den langsamen Prozessoren, die solche Geräte typischerweise haben, deutlich schneller. Der einzige Preis ist die Kompressionsrate, und den zahlt gzip noch stärker als bzip2.

Die Begründung für bzip2 im Besonderen ist deshalb schmal: Der Größenunterschied zwischen gzip und bzip2 wirkt sich beim Übertragen oder beim Flash-Budget tatsächlich spürbar aus, und die zusätzliche Entpackzeit ist tragbar. Trifft das nicht zu, ist gzip das bessere Ziel, und diese Seite bietet es ebenfalls an. Zu wissen, welche der beiden Seiten die richtige ist, hilft mehr als die zufällig zuerst gefundene zu nehmen.

Auf dem eigenen Server, nicht im Browser. Die meisten Werkzeuge hier laufen auf dem eigenen Gerät, und das steht auf der jeweiligen Seite offen — das Umpacken von Archiven ist eine der Ausnahmen, weil dafür 7-Zip und bzip2 als echte Programme gebraucht werden. Die Datei geht über eine verschlüsselte Verbindung in einen Container, der beide betreibt, und dieser Container hat keinen eigenen Internetzugang.

Jeder Auftrag bekommt ein eigenes, frisches Arbeitsverzeichnis, das mit Abschluss des Auftrags gelöscht wird, gleich wie er endet, und was nach sechzig Sekunden noch läuft, wird abgebrochen. Beide Formate sind für sich genommen langsam — xz beim Entpacken eines großen Wörterbuchs, bzip2 beim Komprimieren —, das Zeitlimit ist auf diesem Paar also enger als bei den meisten anderen. Die freie Version nimmt 25 MB je hochgeladener Datei an, und ein Archiv wird schon vor dem Entpacken abgewiesen, wenn es sich auf mehr als 2 GB entfaltet.

Die einzige Prüfung, die hier etwas bedeutet, findet auf dem Zielgerät statt. Die BZ2-Datei auf die Steuerung, den Router oder den Container kopieren, an dem das XZ vorher gescheitert ist, und dort entpacken — nicht auf der eigenen Workstation, wo beide Formate ohnehin funktioniert hätten und die Probe nichts zeigen würde. Fehlt dort auch bzip2, ist das für den Preis einer Dateiübertragung herausgefunden, statt mitten in einer Inbetriebnahme.

Anschließend die Auflistung vergleichen: tar tJf beim XZ und tar tjf beim BZ2 sollten dieselbe Anzahl und dieselben Pfade zeigen. Das Umpacken ist verlustfrei, ein Unterschied ist also nie eine beschädigte Datei, sondern meist ein strukturelles Detail wie ein führendes Verzeichnis, das im einen vorhanden und im anderen nicht vorhanden ist. Stimmen die Listen überein und läuft das Zielgerät damit, kann das XZ gehen.