Convertire BZ2 in GZ

Bzip2 ha avuto un buon decennio. Tra circa il 1998 e il 2010 era la risposta ovvia quando gzip non comprimeva abbastanza, e una grande parte di ciò che è stato pubblicato in quella finestra è ancora `.tar.bz2`: dataset di riferimento, corpora, tarball di kernel e sorgenti, depositi di dati scientifici, la fixture che una suite di test scarica ad ogni esecuzione da prima che chiunque oggi nel team si unisse.

L’archivio non è il problema. Il problema è che qualcosa lo decomprime con un programma, e la decompressione bzip2 è abbastanza lenta da essere visibile in un log di build. Nessuno rifarà il rilascio a monte, quindi la mossa pratica è ricomprimere localmente in qualcosa che si apra rapidamente e mettere quello in cache. È un lettore diverso da chi converte per archiviare, e punta a una risposta diversa: gzip, non XZ.

I due formati si decomprimono in modi strutturalmente diversi e il divario non è una questione di qualità dell’implementazione. L’uscita di gzip è costruita copiando byte letterali e copiando corse precedenti da una finestra di 32 KB — il ciclo interno è essenzialmente movimento di memoria, e l’hardware moderno è estremamente bravo in quello.

Bzip2 deve invertire una trasformata di Burrows–Wheeler per ogni blocco fino a 900 KB. Questo significa ricostruire l’ordinamento originale da una permutazione ordinata, che è un passaggio sparso e ostile alla cache sull’intero blocco prima che un singolo byte di output sia finale, più l’annullamento degli strati move-to-front e Huffman attorno ad esso. È calcolo reale piuttosto che spostamento di dati, e nessuna quantità di tuning lo trasforma in velocità di memoria. Su un archivio di qualsiasi dimensione la differenza è minuti contro secondi.

Aspettatevi che il GZ sia più grande, e aspettatevi che il margine dipenda interamente dal contenuto. Bzip2 vede fino a 900 KB di contesto alla volta dove gzip ne vede 32, quindi su prosa, log, CSV, codice sorgente e XML trova ripetizioni che gzip non può raggiungere e il divario è reale. Il registro registra esattamente quei due numeri, e sono l’intera spiegazione.

Su altri contenuti non c’è divario che valga la pena misurare. Un archivio bzip2 di JPG, PNG, MP3, MP4 o un file di database già compresso è a malapena compresso per cominciare — la ridondanza è stata rimossa da quei formati prima che l’archiviazione iniziasse — quindi ricomprimerlo come gzip costa quasi nulla e compra il pieno beneficio di velocità. Se questo descrive il vostro archivio, questa conversione è quasi gratuita e non c’è nulla da valutare.

Uno stream gzip memorizza il nome del file originale nella sua intestazione. Uno stream bzip2 non memorizza nulla del genere — nessun nome, nessun percorso, nessun indizio su cosa contenga. Quella asimmetria normalmente è una curiosità e ha prodotto un difetto genuino qui, che è registrato nel codice sorgente del convertitore.

Il reimpacchettamento deve scartare il TAR che sta dentro un archivio compresso, e la prima versione del codice decideva se ne aveva trovato uno guardando il nome del file. Da un GZ funzionava, perché gzip aveva ricordato `output.tar`. Da un BZ2 o un XZ lo stesso tarball arrivava chiamato `input`, il controllo lo mancava, e la conversione produceva un archivio contenente un file opaco invece dei trenta che erano entrati — un successo che restituiva la cosa sbagliata. La correzione è stata forzare il tipo tar invece di inferirlo, che è il motivo per cui una sorgente bzip2 oggi è gestita correttamente.

L’ubiquità è la seconda metà dell’argomento di questa conversione ed è facile da sottovalutare. DEFLATE è la compressione dentro HTTP `Content-Encoding: gzip`, dentro PNG, dentro un file ZIP e dentro un oggetto Git. Ogni linguaggio principale ce l’ha nella sua libreria standard — `gzip` di Python, `compress/gzip` di Go, `GZIPInputStream` di Java, `zlib` di Node — senza dipendenze da aggiungere e senza questioni di licenza a cui rispondere.

Bzip2 è una libreria separata che deve essere presente, e in un container minimale, un runtime bloccato, un browser o una cloud function spesso non c’è. Gzip è una codifica di contenuto HTTP registrata e bzip2 non lo è mai stata, quindi ogni client HTTP già ne decomprime uno e nessuno di essi decomprime l’altro. Se l’archivio sarà letto da codice piuttosto che da una persona a una shell, gzip rimuove una dipendenza oltre a un ritardo.

Vale la pena nominare ciò che state dando via piuttosto che solo ciò che guadagnate. Bzip2 comprime ogni blocco indipendentemente, quindi un danno a un blocco non distrugge automaticamente tutto ciò che viene dopo, e strumenti di recupero possono percorrere un file corrotto e salvare i blocchi intatti. Uno stream gzip non ha tale struttura — un bit ribaltato a metà generalmente termina lì l’archivio.

Quanto conta dipende da dove vive il file. Su un filesystem moderno con checksum, su object storage che verifica ciò che restituisce, o ovunque con una seconda copia, conta molto poco. Su un singolo disco invecchiato che contiene l’unica copia di qualcosa di insostituibile, conta di più — e in quel caso la risposta giusta non è nessuno dei due formati ma un backup reale con dati di integrità per file. L’amichevolezza al recupero è un cattivo sostituto della ridondanza.

Se l’archivio viene conservato piuttosto che letto, gzip è la destinazione sbagliata e XZ è quella giusta — comprimerà gli stessi contenuti considerevolmente meglio di quanto abbia fatto bzip2 e si decomprime ancora più velocemente. Il lettore di questa pagina non è quella persona, ma molte persone che convertono un archivio bzip2 lo sono, e vale la pena che venga detto.

Il test è semplice: contate quanto spesso l’archivio viene decompresso. Spesso, da macchine, in un passaggio che qualcuno sta aspettando — gzip. Raramente, da una persona, da un bucket che addebita al gigabyte-mese — XZ. L’unico caso in cui bzip2 dovrebbe restare è una macchina con pochissima memoria, perché i blocchi fissi da 900 KB di bzip2 hanno bisogno di quasi nulla per essere decompressi dove XZ ha bisogno di un buffer scalato sul suo dizionario.

Sul nostro server piuttosto che sul vostro dispositivo. La maggior parte degli strumenti su questo sito converte in locale e lo dice; gli archivi sono una delle eccezioni, perché il lavoro ha bisogno di 7-Zip e gzip come programmi reali. Il file viaggia su una connessione crittata verso un container che li esegue e che non ha accesso a internet in uscita proprio.

Il lavoro ottiene una directory di scratch su un filesystem appoggiato sulla memoria, cancellata nel momento in cui il lavoro finisce che abbia avuto successo o no, e viene terminato dopo sessanta secondi — che su questa coppia è un vincolo reale, dato che bzip2 è lento da decomprimere e un grande archivio di testo è esattamente l’input che prende il suo tempo. Il livello gratuito accetta 25 MB per file caricato, e prima che qualsiasi cosa venga estratta all’archivio viene chiesto cosa dichiara di espandersi, con un totale dichiarato sopra i 2 GB rifiutato subito.

Questa conversione vale la pena farla solo se i numeri lo dicono, e ottenerli è un lavoro di due minuti: cronometrate l’estrazione dell’archivio bzip2, cronometrate l’estrazione di quello gzippato, e mettete le due dimensioni di file accanto ad esse. Se l’archivio è piccolo o la pipeline lo decomprime una volta al mese, il risparmio è rumore e il cambiamento non vale il disturbo di aggiornare qualunque cosa punti al file.

Tenete l’originale bzip2 finché qualcosa non ha effettivamente consumato il nuovo file con successo. Non perché la conversione sia con perdita — non lo è, ogni membro esce byte per byte — ma perché il tarball è ricostruito piuttosto che passato attraverso, quindi ordine dei membri, timestamp e bit di permesso possono spostarsi, e una build che dipendeva da uno di essi fallisce in un modo che non sembra affatto un problema di archivio. Confrontate `tar tjf` sulla sorgente con `tar tzf` sul risultato prima, e mandate in pensione l’originale una volta che concordano.