Waarom schakelen tar-archiefformaten over naar xz-compressie om bzip2 te vervangen en hoe zit het met gzip?

Voor distributie archieven via internet, hebben de volgende dingen over het algemeen prioriteit:

1. Compressieverhouding (dwz hoe klein de compressor de gegevens maakt);
2. Decompressietijd (CPU-vereisten) ;
3. Vereisten voor het decompressiegeheugen; en
4. Compatibiliteit (hoe wijdverspreid het decompressieprogramma is)

Compressiegeheugen & CPU-vereisten zijn niet” t heel belangrijk, omdat je daarvoor een grote snelle machine kunt gebruiken, en je hoeft het maar één keer te doen.

In vergelijking met bzip2 heeft xz een betere compressieverhouding en een kortere (betere) decompressietijd. Het vereist echter – bij de compressie-instellingen die gewoonlijk worden gebruikt – meer geheugen om ^[1] te decomprimeren en is iets minder wijdverspreid. Gzip gebruikt minder geheugen dan beide.

Dus archieven in zowel gzip- als xz-formaat worden gepost, zodat u kunt kiezen uit:

• U moet decomprimeren op een machine met zeer beperkt geheugen (< 32 MB): gzip. Gegeven, niet erg waarschijnlijk als het over kernelbronnen gaat.
• Minimale beschikbare tools moeten decomprimeren: gzip
• Wil downloadtijd en / of bandbreedte besparen: xz

Er is niet echt een realistische combinatie van factoren waardoor je bzip2 zou moeten kiezen. Dus het wordt afgebouwd.

Ik heb compressievergelijkingen bekeken in een blogpost . Ik heb niet geprobeerd de resultaten te repliceren, en ik vermoed dat een deel ervan is veranderd (meestal verwacht ik dat xz is verbeterd, aangezien dit de nieuwste is.)

(Er zijn enkele specifieke scenarios waarin een goede bzip2-implementatie de voorkeur verdient boven xz: bzip2 kan een bestand met veel nullen en genoom-DNA-sequenties beter comprimeren dan xz. Nieuwere versies van xz hebben nu een (optionele) blokmodus waarmee gegevens herstel na het punt van corruptie en parallelle compressie en [in theorie] decompressie. Voorheen bood alleen bzip2 deze aan. ^[2] Maar geen van deze is relevant voor kerneldistributie)

1: In archiefgrootte, xz -3 is ongeveer bzip -9. Dan gebruikt xz minder geheugen om te decomprimeren. Maar xz -9 (zoals bijvoorbeeld gebruikt voor Linux-kerneltarballs) gebruikt veel meer dan bzip -9. (en zelfs xz -0 heeft meer nodig dan gzip -9).

2: F21 systeembrede wijziging: lbzip2 als standaard bzip2-implementatie

Opmerkingen

• Elke opmerking over het onderwerp van fouttolerantie of is dat iets dat ‘ s altijd volledig wordt geïmplementeerd buiten de compressie-algoritmen?
• @illumin É veerkracht kan ‘ niet worden geboden zonder de compressieverhouding op te offeren. Het ‘ is een orthogonaal probleem, en hoewel er tools zoals Parchive bestaan, voor het distribueren van de kernel TCP ‘ s foutafhandeling doet het werk net zoals goed.
• @illumin É Fouttolerantie (ervan uitgaande dat u iets soortgelijks bedoelt met par2) is niet ‘ t normaal gesproken een bezorgdheid over het verspreiden van archieven via internet. Downloads worden verondersteld betrouwbaar genoeg te zijn (en u kunt het gewoon opnieuw downloaden als het beschadigd was). Cryptografische hashes en handtekeningen worden vaak gebruikt en ze detecteren zowel corruptie als geknoei. Er zijn compressoren die een grotere fouttolerantie geven, maar dit gaat ten koste van de compressieverhouding. Niemand lijkt de afweging de moeite waard te vinden voor HTTP- of FTP-downloads.
• xz gebruikt MINDER geheugen om te decomprimeren.
• @Mike Is het veranderd sinds ik dit schreef? In voetnoot 1 wordt met name het geheugengebruik uitgelegd.

Allereerst is deze vraag niet direct gerelateerd naar tar. Tar maakt gewoon een niet-gecomprimeerd archief, de compressie wordt later toegepast.

Het is bekend dat Gzip relatief snel is in vergelijking met LZMA2 en bzip2. Als snelheid ertoe doet, gzip (vooral de multi-threaded implementatie pigz ) is vaak een goed compromis tussen compressiesnelheid en compressieverhouding. Hoewel er alternatieven zijn als snelheid een probleem is (bijv. LZ4).

Echter, als een hoge compressieverhouding gewenst is, verslaat LZMA2 bzip2 in bijna elk aspect. De compressiesnelheid is vaak langzamer, maar het decomprimeert veel sneller en biedt een veel betere compressieverhouding ten koste van een hoger geheugengebruik.

Er is niet veel reden om bzip2 meer, behalve achterwaartse compatibiliteit. Bovendien is LZMA2 ontworpen met het oog op multithreading en maken veel implementaties standaard gebruik van multicore CPUs (helaas doet xz op Linux dit nog niet). Dit is logisch aangezien de kloksnelheden “niet meer toenemen, maar het aantal cores wel.

Er zijn multithreaded bzip2 implementaties (bijv. pbzip ), maar ze worden vaak niet standaard geïnstalleerd. Merk ook op dat multithreaded bzip2 loont alleen echt bij comprimeren , terwijl bij decompressie een enkele thread wordt gebruikt als het bestand werd gecomprimeerd met een enkele thread bzip2, in tegenstelling tot LZMA2. Parallel bzip2 varianten kunnen alleen multicore CPUs gebruiken als het bestand gecomprimeerd is met een parallelle bzip2 versie, wat vaak niet het geval is.

Reacties

• Nou, sommige teeren grok een z optie.
• ” snelheid ” zorgt voor een warrig antwoord, u moet verwijzen naar compressiesnelheid of decompressiesnelheid. Noch pixz, pbzi p2 of pigz worden standaard geïnstalleerd (of gebruikt door tar zonder de vlag -I), maar pixz en pbzip2 versnellen de compressie en decompressie en pigz is alleen voor compressie.
• @Tobu xz zal standaard multithreaded zijn, dus in de toekomst is pixz installatie niet nodig. Op sommige platforms wordt xz al ondersteund. Terwijl bzip2 waarschijnlijk nooit zal worden multithreaded, aangezien het formaat niet ‘ t is ontworpen met het oog op multithreading. Bovendien versnelt pbzip2 de decompressie alleen als het bestand is gecomprimeerd met pbzip2, wat vaak niet het geval is.
• @Marco Ik geloof dat lbzip2 parallelle decompressie van bestanden mogelijk maakt, zelfs als ze zijn gecomprimeerd met een niet-parallelle implementatie (bijvoorbeeld stock bzip2). Daarom ‘ is waarom ik lbzip2 gebruik in plaats van pbzip2. (Het is ‘ mogelijk dat dit is geëvolueerd sinds uw opmerking.)
• This makes sense since the clock speeds won't increase any more – wat? dat ‘ is niet helemaal waar. het bericht is gemaakt in 2014, toen Intel de i3-4370 op 3.8 GHz uitbracht. in 2017 bracht Intel de i7-8700K uit op 4,7 GHz. in 2018 brachten ze de i9-9900K op 5 GHz uit – en er ‘ s waarschijnlijk cpus in 2015 & 2016 dat ‘ s ontbreken ook in deze lijst

LZMA2 is een blokcompressiesysteem terwijl gzip is dat niet. Dit betekent dat LZMA2 zich leent voor multi-threading. Als er corruptie optreedt in een archief, kunt u over het algemeen gegevens uit volgende blokken herstellen met LZMA2, maar u kunt dit niet doen met gzip. In de praktijk verlies je het hele archief met gzip na het beschadigde blok. Met een LZMA2-archief verliest u alleen de bestanden die zijn getroffen door het beschadigde blok (ken). Dit kan belangrijk zijn in grotere archieven met meerdere bestanden.

Opmerkingen

• Dit is inderdaad een zeer nuttig en belangrijk onderscheid!
• Kunt u deze beweringen onderbouwen met bronnen? Ik moet nog een XZ-hersteltool zien, en mijn bekende bron beweert anders: nongnu.org/lzip/xz_inadequate.html

Kort antwoord : xz is efficiënter in termen van compressieverhouding. Het bespaart dus schijfruimte en optimaliseert de overdracht via het netwerk.
U kunt deze Quick Benchmark bekijken om het verschil te ontdekken door praktische tests.

Reacties

• Link is verbroken.
• Nieuwe link: catchchallenger.first -world.info/wiki/…