Convertire GZ in XZ

Nessuno converte un file gzippato che sta per aprire. Chi legge qui sta guardando qualcosa che si è accumulato: un anno di log ruotati, dump notturni del database tenuti per conformità, un dataset di ricerca che deve restare disponibile e che si legge una volta al trimestre, artefatti di CI che nessuno ha cancellato. Il gzip è stata la scelta giusta quando i file sono stati scritti — è veloce, è ovunque, ed era già nella configurazione di rotazione dei log — e non è la scelta giusta per la seconda metà della vita del file.

È qui che si regge l’intera decisione. Il gzip ottimizza per il momento della scrittura e della lettura; XZ ottimizza per gli anni nel mezzo. Se l’archivio verrà recuperato e spacchettato da qualcosa in fretta, o da un dispositivo con pochissima memoria, lasciarlo com’è. Se resterà in archiviazione fredda e verrà letto quasi mai, la conversione è denaro quasi gratuito, e vale la pena farla su tutta la cartella anziché un file alla volta.

Il numero nel registro è l’intera spiegazione. Il gzip, standardizzato come RFC 1952 nel maggio 1996, usa DEFLATE con una finestra di cronologia di 32 KB: quando sta comprimendo il byte un milione, può vedere indietro fino al byte novecentosessantottomila e non oltre. Qualunque cosa si ripetesse prima di quello viene compressa di nuovo da zero, come se non fosse mai stata vista. XZ, del 2009, porta un dizionario che il registro riporta fino a 64 MB — duemila volte la portata.

Ecco perché il guadagno è enorme su alcuni input e nullo su altri. Un anno di righe di log ripete gli stessi quaranta template di messaggio per gigabyte, e il gzip li riscopre migliaia di volte mentre XZ li impara una volta. Un dump SQL ripete i nomi delle colonne su ogni riga. Alberi di sorgenti ripetono intestazioni di licenza, import e boilerplate attraverso centinaia di file. A fronte di ciò, un GZ che contiene una fotografia o un video non ha ripetizione a lungo raggio da trovare, perché la ridondanza era già stata rimossa da JPEG o H.264 prima che il gzip lo vedesse, e il compressore più forte del mondo non può inventare una struttura che non c’è.

Il tempo di compressione è il costo evidente e il meno importante, perché lo paga una macchina che non sta aspettando l’utente. XZ è drasticamente più lento del gzip sullo stesso compito — conseguenza diretta di cercare in un dizionario duemila volte più grande — e per un lavoro che si esegue di notte su un bucket di archiviazione, non è un problema che valga la pena ottimizzare.

La memoria in decompressione è il costo che decide davvero le cose, ed è quello che le persone trascurano. Il gzip ha bisogno della sua finestra di 32 KB per decomprimere, cioè nulla; XZ ha bisogno di un buffer scalato sul dizionario con cui il file è stato scritto. Su un portatile o un server è irrilevante. Su un router, un piccolo dispositivo embedded, un container con limite di memoria o un agente di build con limiti stretti, è la differenza fra l’archivio che si apre e il processo che viene terminato. Verificare la macchina che decomprimerà il file, non quella che lo comprime.

Entrambi i formati comprimono esattamente un flusso, quindi nessuno dei due sa cos’è una directory. In pratica un `.gz` è quasi sempre un `.tar.gz`: un TAR che porta i nomi e le cartelle, con il gzip avvolto attorno. La conversione toglie entrambi gli strati, poi rimette entrambi — i membri vengono raccolti in un TAR fresco e quel TAR viene compresso con xz.

Il caso che vale la pena conoscere è quello in cui la sorgente non era un tarball. Un semplice `access.log.gz` contiene un file ordinario, e il reimpacchettamento costruisce comunque un TAR attorno, quindi ciò che torna è un tarball che contiene `access.log` anziché un file compresso isolato. È innocuo se lo si decomprime con `tar xJf` e fonte di confusione se si prova `unxz` e si trova un file chiamato `output.tar`. Se la propria toolchain si aspetta un singolo flusso compresso senza nulla avvolto attorno, questo è il dettaglio da pianificare.

Un flusso gzip ha un campo header per il nome originale del file, ed è per questo che decomprimere `dump.gz` su una macchina Unix può restituire `dump.sql` anche se nulla nell’estensione lo diceva. XZ non ha un campo del genere. Memorizza un controllo di integrità e nulla su dove venissero i dati.

Ciò ha una conseguenza pratica a entrambe le estremità di questa conversione, e ha causato un vero bug in questo convertitore, registrato nel codice: poiché il gzip memorizza un nome e xz no, un tarball interno arriva da un GZ con un nome sensato e da un XZ con qualunque nome abbia scelto l’estrattore. La correzione è stata forzare il tipo tar anziché inferirlo dal nome. Per chi legge, la lezione è più semplice — l’estensione che si mette sul file XZ scaricato è l’unica etichetta che porterà per sempre, quindi chiamarlo `qualcosa.tar.xz` e farlo davvero.

Entrambi i formati si verificano da soli, il che è uno dei motivi per cui questa conversione è sicura da eseguire senza supervisione. Un flusso gzip termina con un CRC-32 e la lunghezza non compressa; un flusso XZ porta il proprio controllo, CRC-64 di default, sui dati non compressi. In entrambi i casi un download troncato o un bit capovolto produce un errore in decompressione anziché un file che in silenzio legge corto.

Ciò che nessuno dei due può fare è dire quale file sia danneggiato, perché a quel livello non ci sono file. Uno ZIP o un 7Z registra un checksum per voce e può segnalare che un membro su quaranta è corrotto; un flusso compresso può solo segnalare che il flusso è corrotto. Se l’integrità per membro è ciò che serve da un archivio — perché si intende recuperare il resto quando una parte marcisce — allora un compressore a flusso è la forma sbagliata per il lavoro indipendentemente da quanto comprime bene.

Questa conversione non gira sul proprio dispositivo. La maggior parte degli strumenti su questo sito tiene il file in locale e lo dichiara; reimpacchettare archivi è una delle eccezioni, perché servono 7-Zip e xz come programmi reali. Il file va su una connessione cifrata verso un container che li esegue, e il container non ha accesso a internet in uscita.

Ogni lavoro riceve una directory di scratch su un filesystem in memoria, e quella directory viene eliminata non appena il lavoro termina indipendentemente dal fatto che sia andato a buon fine. Qualsiasi cosa sia ancora in esecuzione dopo sessanta secondi viene terminata — un archivio malformato manda un compressore in loop molto più spesso di quanto non lo faccia fallire. Il piano gratuito accetta 25 MB per file caricato, che per un archivio di log gzippato è un mucchio di testo ma è un vero tetto per un dataset.

BZ2 è l’altra risposta tradizionale al "gzip non mi comprime abbastanza", e sulla maggior parte dei testi ora perde contro XZ su entrambi gli assi in una volta — rapporto peggiore e decompressione più lenta. Il registro segna BZ2 come legacy per questa ragione. Il suo unico vantaggio residuo è l’altra faccia del punto sulla memoria: bzip2 lavora in blocchi fino a 900 KB, quindi decomprimerne uno non ha mai bisogno di molta memoria.

Quindi la scelta non riguarda davvero il rapporto. Scegliere XZ quando la macchina che decomprimerà l’archivio è un computer ordinario, che di solito è così, e scegliere BZ2 solo quando non lo è — un apparecchio vecchio, un container vincolato, un sistema dove xz non è installato e non può esserlo. Scegliere BZ2 per la sola compressione è una decisione di circa il 2005 che non è più vera da molto tempo.

Fare prima un file e guardare le due dimensioni. Un singolo archivio rappresentativo dice ciò che il resto della cartella farà molto più affidabilmente di qualsiasi regola pratica, perché la risposta è decisa dal contenuto anziché dai formati — la stessa conversione che dimezza un archivio di log non fa nulla a una cartella di fotografie. Se il primo file si muove appena, fermarsi: si è appreso che i dati non hanno ridondanza a lungo raggio e nessun compressore ne troverà.

Poi controllare l’elenco, non solo la dimensione. Eseguire `tar tJf` sul risultato e confrontare il numero delle voci e i percorsi con ciò che il GZ conteneva, in particolare il livello superiore: un archivio impacchettato dall’interno di una directory e uno impacchettato dal suo genitore differiscono per una cartella iniziale in ogni percorso, e quella differenza rompe gli script molto tempo dopo che nessuno ricorda di aver convertito qualcosa. Una volta che l’elenco corrisponde e la dimensione è quella attesa, l’originale non ha più un lavoro da fare.