BZ2 in GZ umwandeln

Ein Rechenzentrum einer Universität oder ein Forschungsdatenrepositorium liefert Referenzdatensätze noch häufig als `.tar.bz2` aus — bioinformatische Sequenzdaten, ein Korpus für die Sprachverarbeitung, ein Kernel- oder Quell-Tarball, der seit Jahren unverändert dort liegt. Niemand wird die Veröffentlichung neu bauen, nur um das Kompressionsformat zu ändern.

Das eigentliche Problem taucht dort auf, wo dieses Archiv nicht einmal, sondern regelmäßig entpackt wird: ein CI-Job, der die Fixture bei jedem Lauf lädt, eine Analyse-Pipeline, die den Datensatz bei jedem Start neu auspackt. Genau dann wird bzip2s langsame Entpackzeit im Build-Log sichtbar, und die sinnvolle Reaktion ist, lokal in etwas umzupacken, das schnell aufgeht, statt an der Quelle etwas zu ändern.

Gzip baut seine Ausgabe, indem es Bytes wörtlich kopiert oder frühere Abschnitte innerhalb eines 32-KB-Fensters zurückverweist — im Kern eine Speicheroperation, in der moderne Prozessoren außerordentlich schnell sind. Bzip2 dagegen muss für jeden Block von bis zu 900 KB eine Burrows-Wheeler-Transformation rückgängig machen: eine wahllos über den ganzen Block springende, für den Prozessor-Cache ungünstige Rekonstruktion der ursprünglichen Reihenfolge, bevor auch nur ein einziges Ausgabebyte feststeht.

Das ist echte Rechenarbeit statt Datenverschiebung, und keine Optimierung macht daraus Speichergeschwindigkeit. Bei einem Archiv von einiger Größe ist der Unterschied nicht messbar knapp, sondern Minuten gegen Sekunden.

Bzip2 sieht bis zu 900 KB Kontext auf einmal, gzip nur 32 KB, deshalb findet bzip2 in Fließtext, Logdateien, CSV, Quellcode und XML Wiederholungen, die gzip entgehen — bei solchen Inhalten fällt die GZ-Datei spürbar größer aus. Wie viel genau, hängt vollständig vom Inhalt ab, nicht von einer festen Regel.

Bei bereits komprimierten Inhalten gibt es dagegen praktisch nichts zu verlieren: Ein bzip2-Archiv voller JPEGs, MP3s, MP4s oder einer bereits komprimierten Datenbankdatei war von Anfang an kaum komprimierbar, weil die Redundanz schon vor dem Archivieren durch das jeweilige Format entfernt wurde. In diesem Fall kostet das Umpacken fast nichts und bringt den vollen Geschwindigkeitsgewinn.

DEFLATE, gzips Kompressionsverfahren, steckt in HTTP `Content-Encoding: gzip`, in PNG, in ZIP-Dateien und in Git-Objekten. Jede verbreitete Programmiersprache hat es in der Standardbibliothek — Pythons `gzip`, Gos `compress/gzip`, Javas `GZIPInputStream`, Node.js’ `zlib` —, ohne zusätzliche Abhängigkeit und ohne Lizenzfrage.

Bzip2 ist eine separate Bibliothek, die erst vorhanden sein muss, und in einem schlanken Container-Image, einer abgeschotteten Laufzeitumgebung oder einer Cloud-Funktion fehlt sie häufig. Gzip ist außerdem eine registrierte HTTP-Content-Codierung, bzip2 war es nie — jeder HTTP-Client entpackt das eine bereits mitgebracht und keiner das andere. Wird das Archiv von Software statt von einer Person am Terminal gelesen, entfällt mit gzip eine ganze Abhängigkeit.

Zwischen etwa 1998 und 2010 war bzip2 die naheliegende Wahl, wenn gzip nicht genug komprimierte, und ein erheblicher Teil dessen, was in dieser Zeit auf deutschen und internationalen Servern veröffentlicht wurde, liegt bis heute als `.tar.bz2` dort — inklusive einiger Datensätze, die von deutschen Forschungseinrichtungen und Hochschulrechenzentren aus dieser Ära stammen. Diese Archive werden niemand neu erstellen; sie werden lediglich lokal in ein handlicheres Format umgepackt.

Bzip2 behält dabei einen genuinen Vorteil: Es braucht sehr wenig Arbeitsspeicher zum Entpacken. Deshalb überlebt es auf kleinen Geräten und in Rezepten, die es namentlich vorschreiben — der einzige Fall, in dem an bzip2 festzuhalten weiterhin sinnvoll ist.

Jede enthaltene Datei kommt byteidentisch heraus — beide Formate arbeiten verlustfrei. Was nicht zwangsläufig übersteht, ist das, was der Container über die Dateien wusste, statt es in ihnen zu tragen: Zugriffsrechte und Zeitstempel, weil das Tarball beim Umpacken aus den entpackten Inhalten neu aufgebaut wird, statt unverändert durchgereicht zu werden.

Für einen reinen Datensatz ist das meist irrelevant. Bei einem Archiv, das ein Startskript oder ausführbare Dateien enthält, lohnt sich ein kurzer Vergleich der beiden Inhaltslisten, bevor die alte Datei gelöscht wird.

Wird das Archiv aufbewahrt statt regelmäßig gelesen, ist gzip die falsche Zieladresse und XZ die richtige — es komprimiert deutlich besser als bzip2 und entpackt trotzdem schneller. Wer diese Seite über eine Suchmaschine erreicht hat, meint aber meist das andere Problem: eine Datei, die oft und maschinell entpackt wird.

Die Faustregel ist einfach: Häufig, maschinell, in einem Schritt, auf den jemand wartet — gzip. Selten, von Hand, aus einem Speicher, der nach Gigabyte-Monat abrechnet — XZ. Bei bzip2 bleiben sollte nur, wer auf einem Gerät mit sehr wenig Arbeitsspeicher entpackt.

Debian und Ubuntu haben ihre eigenen Paketformate über die Jahre nicht bei bzip2 belassen, sondern zu XZ und später teilweise zu zstd weiterentwickelt — aus genau demselben Grund, aus dem diese Umwandlung existiert: Ein Paketmanager entpackt ständig, und die Entpackzeit zählt dort direkt in die Wartezeit eines `apt install` hinein.

Das ist kein Zufall, sondern derselbe Kompromiss aus einer anderen Richtung: Wo bzip2 überhaupt noch als Standardformat auftaucht, sind es meist ältere Datensätze oder Archive, die niemand aus Bequemlichkeit neu veröffentlicht hat — nicht neue Software, die sich bewusst dafür entschieden hätte.

Diese Umwandlung läuft auf unserem Server statt im Browser, weil sie 7-Zip und gzip als echte Programme braucht. Die Datei geht über eine verschlüsselte Verbindung an einen Container ohne eigenen Internetzugang; das Arbeitsverzeichnis wird nach Abschluss des Auftrags gelöscht, auch bei einem Fehlschlag.

Der Auftrag wird nach sechzig Sekunden pro Verarbeitungsschritt abgebrochen — auf diesem Paar eine echte Grenze, weil bzip2 langsam entpackt und ein großes Textarchiv genau das ist, was Zeit kostet. Frei sind 25 MB je hochgeladener Datei, und bevor überhaupt etwas entpackt wird, prüft der Dienst die deklarierte Entpackgröße; eine Angabe über 2 GB wird von vornherein abgelehnt.

Ob sich das Umpacken lohnt, lässt sich in zwei Minuten prüfen: einmal die Entpackzeit des bzip2-Archivs stoppen, einmal die des gezippten Ergebnisses, dazu die beiden Dateigrößen. Ist das Archiv klein oder wird es nur einmal im Monat entpackt, ist die Ersparnis Rauschen, und der Aufwand, überall die Referenz umzustellen, lohnt sich nicht.

Das bzip2-Original sollte bis dahin liegen bleiben — nicht wegen möglicher Verluste, denn jede Datei kommt byteidentisch heraus, sondern weil das Tarball neu aufgebaut wird und Reihenfolge, Zeitstempel und Rechte sich dadurch leicht verschieben können. Ein Build, der genau davon abhängt, scheitert dann auf eine Weise, die nach allem aussieht, nur nicht nach einem Archivproblem.

Ein GZ-Stream speichert den ursprünglichen Dateinamen im Header, ein BZ2-Stream nicht — keinen Namen, keinen Pfad, keinen Hinweis darauf, was er enthält. Diese Asymmetrie ist normalerweise eine Randnotiz, aber beim Auspacken eines darin verpackten TAR wird nicht der Dateiname geprüft, um zu erkennen, ob eines vorliegt, sondern der tatsächliche Inhalt — sonst würde ein aus einer BZ2 gewonnenes Tarball, das keinen sprechenden Namen mitbringt, schlicht übersehen.

Praktisch heißt das: Ein Archiv, dessen Inhalt aus mehreren Dateien besteht, wird auch dann korrekt erkannt und vollständig entpackt, wenn die Quelle selbst keine einzige Information über ihren Inhalt trägt — genau das, was ein bzip2-Datensatz aus einem Universitätsrechenzentrum in der Regel ist.