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

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

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

Memoria di compressione & I requisiti della CPU non sono” t molto importante, perché puoi usare una grande macchina veloce per quello, e devi farlo solo una volta.

Rispetto a bzip2, xz ha un rapporto di compressione migliore e un tempo di decompressione più basso (migliore). Tuttavia, con le impostazioni di compressione tipicamente utilizzate, richiede più memoria per decomprimere ^[1] ed è un po meno diffuso. Gzip usa meno memoria di entrambi.

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

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

Non esiste una combinazione realistica di fattori che “ti inducano a scegliere bzip2. Quindi è stato gradualmente eliminato.

Ho esaminato i confronti della compressione in un post del blog . Non ho tentato di replicare i risultati e sospetto che alcuni di essi siano cambiati (principalmente, mi aspetto che xz sia migliorato, poiché è 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 i dati recupero dopo il punto di corruzione e compressione parallela e [in teoria] decompressione. In precedenza, solo bzip2 li offriva. ^[2] Tuttavia nessuno di questi è rilevante per la distribuzione del kernel)

1: Nella dimensione dellarchivio, xz -3 è di circa bzip -9. Quindi xz utilizza meno memoria per decomprimere. Ma xz -9 (come, ad esempio, utilizzato per i tarball del kernel Linux) usa molto più di bzip -9. (E anche xz -0 richiede più di gzip -9).

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

Commenti

• Qualsiasi commento sullargomento di tolleranza agli errori o è qualcosa che ‘ viene sempre implementato completamente al di fuori degli algoritmi di compressione?
• @illumin É la resilienza può ‘ essere fornita senza sacrificare il rapporto di compressione. È ‘ un problema ortogonale e, sebbene esistano strumenti come Parchive, per la distribuzione del kernel TCP ‘ la gestione degli errori fa il lavoro proprio come bene.
• @illumin É La tolleranza agli errori (supponendo che tu intenda qualcosa di simile a par2) non è ‘ normalmente una preoccupazione per la distribuzione di archivi su Internet. Si presume che i download siano sufficientemente affidabili (e puoi semplicemente scaricarli di nuovo se è danneggiato). Gli hash e le firme crittografici vengono spesso utilizzati e rilevano il danneggiamento e la manomissione. Ci sono compressori che offrono una maggiore tolleranza ai guasti, anche se a scapito del rapporto di compressione. Nessuno sembra trovare il compromesso che valga la pena per i download HTTP o FTP.
• xz usa MENO memoria per decomprimere.
• @Mike È cambiato da quando ho scritto questo? In particolare, la nota uno spiega lutilizzo della memoria.

Prima di tutto, questa domanda non è direttamente correlata a tar. Tar crea semplicemente 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 limplementazione 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 rapporto di compressione elevato, LZMA2 batte bzip2 in quasi ogni aspetto. La velocità di compressione è spesso più lenta, ma si decomprime molto più velocemente e fornisce un rapporto di compressione molto migliore al costo di un maggiore utilizzo della memoria.

Non cè motivo di usare bzip2 più, tranne che per compatibilità allindietro. Inoltre, LZMA2 è stato progettato pensando al multithreading e molte implementazioni di default fanno uso di CPU multicore (sfortunatamente xz su Linux non lo fa ancora). Questo ha senso poiché le velocità di clock non aumenteranno più, ma il numero di core sì.

Ci sono implementazioni bzip2 multithread (ad es. pbzip ), ma spesso non sono installati per impostazione predefinita. Tieni inoltre presente che i bzip2 multithread solo durante la compressione , mentre la decompressione utilizza un singolo thread se il file è stato compresso utilizzando un unico thread bzip2, in contrasto con LZMA2. Parallelo bzip2 le varianti possono sfruttare CPU multicore solo se il file è stato compresso utilizzando una versione bzip2 parallela, che spesso non è il caso.

Commenti

• Beh, alcuni catrami gridano unopzione z.
• ” velocità ” fornisce una risposta confusa, dovresti fare riferimento alla velocità di compressione o alla velocità di decompressione. Né pixz, pbzi p2 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 xz sarà multithread per impostazione predefinita, quindi in futuro non sarà richiesta alcuna installazione di pixz. Su alcune piattaforme xz è già supportato il threading. Mentre bzip2 difficilmente sarà mai multithreading poiché il formato non è stato ‘ progettato pensando al multithreading. Inoltre, pbzip2 accelera la decompressione solo se il file è stato compresso utilizzando pbzip2 che spesso non è il caso.
• @Marco Credo che lbzip2 consenta la decompressione parallela dei file anche se sono stati compressi con unimplementazione non parallela (es. Stock bzip2). Questo è ‘ perché uso lbzip2 su pbzip2. (È ‘ possibile che si sia evoluto dopo il tuo commento.)
• This makes sense since the clock speeds won't increase any more – cosa? questo ‘ non è del tutto vero. il post è stato pubblicato nel 2014, quando Intel ha rilasciato li3-4370 a 3,8 GHz. nel 2017, Intel ha rilasciato i7-8700K a 4,7 GHz. nel 2018 hanno rilasciato li9-9900K a 5 GHz e nel 2015 & 2016 iv id = “7906c8428b probabilmente ci sono ‘ “>

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, è generalmente possibile ripristinare i dati dai blocchi successivi con LZMA2 ma non è possibile farlo con gzip. In pratica si perde lintero archivio con gzip successivamente al 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.

Commenti

• Questa è una distinzione molto utile e importante, davvero!
• Puoi eseguire il backup di queste affermazioni con le fonti? Devo ancora vedere uno strumento di ripristino XZ e la mia fonte nota afferma il contrario: nongnu.org/lzip/xz_inadequate.html

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 per scoprire la differenza con test pratici.

Commenti

• Link interrotto.
• Nuovo link: catchchallenger.first -world.info/wiki/…