BZ2 naar GZ omzetten

Bzip2 had een goede periode: van ongeveer 1998 tot 2010 was het het voor de hand liggende antwoord als gzip niet genoeg comprimeerde, en veel wat toen gepubliceerd werd is nog altijd .tar.bz2 — referentiedatasets, broncode-tarballs, de fixture die een testsuite al jarenlang bij elke run opnieuw downloadt.

Het archief zelf is niet het probleem. Het probleem is dat iets het regelmatig uitpakt, en bzip2-decompressie is traag genoeg om zichtbaar te zijn in een buildlog. Niemand gaat de release opnieuw uitbrengen, dus de praktische stap is lokaal herpakken naar iets dat snel opent en dat cachen.

De twee formaten decomprimeren structureel anders, en het verschil is geen kwestie van implementatie. De uitvoer van gzip wordt opgebouwd door letterlijke bytes te kopiëren en eerdere reeksen uit een venster van 32 KB te herhalen — vrijwel geheugenverplaatsing, en moderne hardware is daar extreem goed in.

Bzip2 moet voor elk blok van tot 900 KB een Burrows-Wheeler-transformatie terugdraaien: de oorspronkelijke volgorde reconstrueren uit een gesorteerde permutatie, een verspreide, cache-onvriendelijke bewerking over het hele blok. Dat is echte rekenkracht, geen geheugenverplaatsing, en geen enkele tuning verandert dat.

Verwacht dat de GZ groter wordt, en verwacht dat de marge volledig van de inhoud afhangt. Bzip2 ziet tot 900 KB context tegelijk waar gzip er 32 KB ziet, dus bij proza, logs, CSV, broncode en XML vindt bzip2 herhaling die gzip niet bereikt.

Bij andere inhoud is er nauwelijks verschil. Een bzip2-archief van JPEG’s, PNG’s, MP3’s of MP4’s is al nauwelijks gecomprimeerd, dus herpakken als gzip kost bijna niets en levert het volledige snelheidsvoordeel op.

Een gzip-stream bewaart de oorspronkelijke bestandsnaam in de header. Een bzip2-stream bewaart daar niets van — geen naam, geen pad, geen aanwijzing. Die asymmetrie leverde hier ooit een echte fout op.

De herpakstap moet de TAR uitpakken die in het gecomprimeerde archief zit, en de eerste versie van de code herkende die aan de bestandsnaam. Vanaf een BZ2 heette diezelfde tarball «input», de controle miste hem, en het resultaat was één ondoorzichtig bestand in plaats van de dertig die erin gingen. Inmiddels wordt het tar-type afgedwongen in plaats van geraden.

Alomtegenwoordigheid is de tweede helft van dit argument. DEFLATE zit in HTTP Content-Encoding: gzip, in PNG, in een ZIP-bestand en in een Git-object. Elke gangbare taal heeft het in de standaardbibliotheek, zonder extra afhankelijkheid.

Bzip2 is een aparte bibliotheek die aanwezig moet zijn, en in een minimale container, een browser of een cloudfunctie is dat vaak niet zo. Gzip is een geregistreerde HTTP-content-coding, bzip2 nooit geweest.

Bzip2 comprimeert elk blok apart, dus schade aan één blok verwoest niet automatisch alles erna, en herstelprogramma’s kunnen een beschadigd bestand doorlopen en de intacte blokken redden. Een gzip-stream heeft die structuur niet.

Hoe erg dat is, hangt af van waar het bestand staat: op een moderne bestandssysteem met checksums maakt het weinig uit; op één verouderende schijf met de enige kopie van iets onvervangbaars maakt het meer uit — en dan is een echte back-up met integriteitsdata het echte antwoord, niet het archiefformaat.

Wordt het archief bewaard in plaats van gelezen, dan is gzip het verkeerde doel en XZ het juiste: het comprimeert aanzienlijk beter dan bzip2 en pakt nog steeds sneller uit.

De test is simpel: tel hoe vaak het archief wordt uitgepakt. Vaak, door machines, in een stap waar iemand op wacht — gzip. Zelden, door een mens, uit opslag die per gigabyte-maand rekent — XZ. Bzip2 blijft alleen zinvol op een machine met heel weinig geheugen.

Op onze server, niet op je eigen apparaat. De meeste tools op deze site zetten lokaal om; archieven zijn een van de uitzonderingen, omdat het werk echte programma’s als 7-Zip en gzip vereist. De container heeft zelf geen toegang tot het internet.

De taak krijgt een tijdelijke map op een geheugengebaseerd bestandssysteem, die na afloop altijd wordt verwijderd, en wordt na zestig seconden afgebroken — bij bzip2 een reële beperking, want decompressie is traag. Het gratis niveau accepteert 25 MB per bestand, en een opgave van meer dan 2 GB uitgepakt wordt vooraf geweigerd.

Deze omzetting loont alleen als de cijfers dat bevestigen: meet de uitpaktijd van het bzip2-archief, meet die van het gzip-archief, en zet de twee bestandsgroottes ernaast. Is het archief klein of wordt het maar één keer per maand uitgepakt, dan is de winst ruis.

Bewaar het bzip2-origineel tot iets het nieuwe bestand echt succesvol heeft gebruikt. Niet omdat de omzetting lossy is — dat is ze niet — maar omdat de tarball opnieuw wordt opgebouwd, waardoor volgorde, tijdstempels en rechten kunnen verschuiven. Vergelijk eerst tar tjf met tar tzf voor je het origineel wegdoet.