Perché i formati di archivio tar stanno passando alla compressione xz per sostituire bzip2 e che dire di gzip?


202

Sempre più tararchivi utilizzano il xzformato basato su LZMA2 per la compressione anziché la bzip2(bz2)compressione tradizionale . In effetti kernel.org ha fatto un annuncio tardivo di " Arrivederci bzip2 " , il 27 dicembre 2013 , indicando che le fonti del kernel da questo punto in poi sarebbero state rilasciate sia in formato tar.gz che tar.xz - e sulla pagina principale del sito Web ciò che è direttamente offerto è in tar.xz.

Ci sono ragioni specifiche che spiegano perché ciò sta accadendo e qual è la rilevanza gzipin questo contesto?

history  gzip  bzip2  xz 

Risposte:


198

Per la distribuzione di archivi su Internet, le seguenti cose sono generalmente una priorità:

  1. Rapporto di compressione (ovvero, quanto è piccolo il compressore rende i dati);
  2. Tempo di decompressione (requisiti CPU);
  3. Requisiti di memoria di decompressione; e
  4. Compatibilità (quanto è diffuso il programma di decompressione)

I requisiti di memoria di compressione e CPU non sono molto importanti, perché è possibile utilizzare una macchina veloce di grandi dimensioni per questo, e devi farlo solo una volta.

Rispetto a bzip2, xz ha un rapporto di compressione migliore e un tempo di decompressione (migliore) inferiore. Tuttavia, con le impostazioni di compressione generalmente utilizzate, richiede più memoria per decomprimere [1] ed è in qualche modo meno diffuso. Gzip utilizza meno memoria di entrambi.

Quindi, vengono pubblicati sia gli archivi in ​​formato gzip che xz, che consentono di scegliere:

  • È necessario decomprimere su una macchina con memoria molto limitata (<32 MB): gzip. Dato, non molto probabilmente quando si parla di sorgenti del kernel.
  • È necessario decomprimere gli strumenti minimi disponibili: gzip
  • Vuoi risparmiare tempo di download e / o larghezza di banda: xz

Non esiste davvero una combinazione realistica di fattori che ti inducano a scegliere bzip2. Quindi viene gradualmente eliminato.

Ho esaminato i confronti di compressione in un post sul blog . Non ho tentato di replicare i risultati e sospetto che alcuni di essi siano cambiati (principalmente, mi aspetto che xzsia migliorato, essendo il più recente).

(Ci sono alcuni scenari specifici in cui una buona implementazione di bzip2 può essere preferibile a xz: bzip2 può comprimere un file con molti zeri e sequenze di DNA del genoma meglio di xz. Le versioni più recenti di xz ora hanno una modalità di blocco (opzionale) che consente il recupero dei dati dopo il punto di corruzione, compressione parallela e [in teoria] decompressione. In precedenza, solo bzip2 offriva questi. [2] Tuttavia nessuno di questi è rilevante per la distribuzione del kernel)


1: nelle dimensioni dell'archivio, xz -3è in giro bzip -9. Quindi xz utilizza meno memoria per decomprimere. Ma xz -9(come, ad esempio, usato per i tarball del kernel Linux) ne usa molto di più bzip -9. (E ha xz -0bisogno anche di più di gzip -9).

2: F21 Modifica a livello di sistema: lbzip2 come implementazione predefinita di bzip2


Qualche commento sul tema della tolleranza agli errori o è qualcosa che è sempre implementato completamente al di fuori degli algoritmi di compressione?

1
La resilienza di @ illuminÉ non può essere fornita senza sacrificare il rapporto di compressione. È un problema ortogonale e mentre esistono strumenti come Parchive, per distribuire la gestione degli errori del kernel TCP fa altrettanto bene.
Tobu,

2
@ illuminÉ La tolleranza agli errori (supponendo che tu intenda qualcosa di simile al par2) non è normalmente un problema con la distribuzione di archivi su Internet. I download sono considerati abbastanza affidabili (e puoi semplicemente scaricarli di nuovo se sono stati danneggiati). Gli hash e le firme crittografiche vengono spesso utilizzati e rilevano la corruzione e la manomissione. Esistono compressori che offrono una maggiore tolleranza ai guasti, sebbene a costo del rapporto di compressione. Nessuno sembra trovare il valore giusto per i download HTTP o FTP.
derobert,

xz usa la memoria MENO per decomprimere.
MichalH

@Mike È cambiato da quando ho scritto questo? In particolare, la nota 1 spiega l'utilizzo della memoria.
derobert l'

45

Prima di tutto, questa domanda non è direttamente correlata tar. Tar crea solo un archivio non compresso, la compressione viene quindi applicata in seguito.

Gzip è noto per essere relativamente veloce rispetto a LZMA2 e bzip2. Se la velocità è importante, gzip(in particolare l'implementazione multithread pigz) è spesso un buon compromesso tra velocità di compressione e rapporto di compressione. Sebbene ci siano alternative se la velocità è un problema (ad esempio LZ4).

Tuttavia, se si desidera un elevato rapporto di compressione, LZMA2 batte bzip2in quasi tutti gli aspetti. La velocità di compressione è spesso più lenta, ma si decomprime molto più velocemente e offre un rapporto di compressione molto migliore a scapito di un maggiore utilizzo della memoria.

Non c'è più motivo di usarlo bzip2più, tranne la compatibilità con le versioni precedenti. Inoltre, LZMA2 è stato progettato pensando al multithreading e molte implementazioni di default utilizzano CPU multicore (sfortunatamente xzsu Linux non lo fa ancora). Questo ha senso poiché le velocità di clock non aumenteranno più, ma il numero di core lo farà.

Esistono bzip2implementazioni multithread (ad esempio pbzip), ma spesso non vengono installate per impostazione predefinita. Si noti inoltre che il multithread bzip2paga davvero solo durante la compressione, mentre la decompressione utilizza un singolo thread se il file è stato compresso utilizzando un singolo thread bzip2, al contrario di LZMA2. Le bzip2varianti parallele possono sfruttare le CPU multicore solo se il file è stato compresso utilizzando una bzip2versione parallela , che spesso non è il caso.


4
Beh, alcuni tars grok zun'opzione.
tchrist

"speed" fornisce una risposta confusa, è necessario fare riferimento alla velocità di compressione o alla velocità di decompressione. Né pixz, pbzip2 o pigz sono installati di default (o usati da tar senza il flag -I), ma pixz e pbzip2 accelerano la compressione e la decompressione e pigz è solo per la compressione.
Tobu

@Tobu xzsarà multithread per impostazione predefinita, quindi pixzin futuro non sarà richiesta alcuna installazione. Su alcune piattaforme il xzthreading è già supportato. Considerando bzip2che probabilmente non sarà mai multithread poiché il formato non è stato progettato pensando al multithreading. Inoltre, pbzip2accelera la decompressione solo se il file è stato compresso utilizzando il pbzip2che spesso non è il caso.
Marco

1
@Marco Credo che lbzip2 consenta la decompressione parallela dei file anche se sono stati compressi con un'implementazione non parallela (ad esempio stock bzip2). Ecco perché uso lbzip2 su pbzip2. (È possibile che questo si sia evoluto dal tuo commento.)
RaveTheTadpole

19

Risposta breve : xz è più efficiente in termini di rapporto di compressione. Quindi risparmia spazio su disco e ottimizza il trasferimento attraverso la rete.
Puoi vedere questo Quick Benchmark in modo da scoprire la differenza con test pratici.


Il collegamento è interrotto.
flarn2006,

18

LZMA2 è un sistema di compressione a blocchi mentre gzip non lo è. Ciò significa che LZMA2 si presta al multi-threading. Inoltre, se si verifica un danneggiamento in un archivio, in genere è possibile recuperare i dati dai blocchi successivi con LZMA2 ma non è possibile farlo con gzip. In pratica, perdi l'intero archivio con gzip dopo il blocco danneggiato. Con un archivio LZMA2, perdi solo i file interessati dai blocchi danneggiati. Questo può essere importante in archivi più grandi con più file.


2
Questa è una distinzione molto utile e importante, davvero!
Leden
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.