Hvorfor bytter tjærearkivformat til xz-komprimering for å erstatte bzip2, og hva med gzip?

For distribusjon arkiver over Internett, er følgende ting generelt prioritert:

1. Kompresjonsforhold (dvs. hvor liten kompressoren lager dataene);
2. Dekompresjonstid (CPU-krav) ;
3. Krav til dekomprimeringsminne og
4. Kompatibilitet (hvor bredt spredt dekompresjonsprogram er)

Komprimeringsminne & CPU-krav er ikke veldig viktig, fordi du kan bruke en stor rask maskin til det, og du trenger bare å gjøre det en gang.

Sammenlignet med bzip2 har xz bedre kompresjonsforhold og lavere (bedre) dekompresjonstid. Det krever imidlertid mer minne for å dekomprimere ^[1] – ved kompresjonsinnstillingene som vanligvis brukes – og er noe mindre utbredt. Gzip bruker mindre minne enn noen av dem.

Så, både gzip- og xz-formatarkiv blir lagt ut, slik at du kan velge:

• Trenger å dekomprimere på en maskin med veldig begrenset minne (< 32 MB): gzip. Gitt, ikke veldig sannsynlig når du snakker om kjernekilder.
• Trenger å dekomprimere minimale tilgjengelige verktøy: gzip
• Vil du spare nedlastingstid og / eller båndbredde: xz

Det er ikke en realistisk kombinasjon av faktorer som får deg til å velge bzip2. Så det blir faset ut.

Jeg så på kompresjonssammenligninger i et blogginnlegg . Jeg prøvde ikke å replikere resultatene, og jeg mistenker at noe av det har endret seg (for det meste forventer jeg at xz har blitt bedre, siden det er det nyeste.)

(Det er noen spesifikke scenarier der en god bzip2-implementering kan være å foretrekke fremfor xz: bzip2 kan komprimere en fil med mange nuller og genom-DNA-sekvenser bedre enn xz. Nyere versjoner av xz har nå en (valgfri) blokkeringsmodus som tillater data gjenoppretting etter korrupsjon og parallell komprimering og [i teorien] dekompresjon. Tidligere tilbød bare bzip2 disse. ^[2] Imidlertid er ingen av disse relevante for kjernedistribusjon)

1: I arkivstørrelse er xz -3 rundt bzip -9. Da bruker xz mindre minne til å dekomprimere. Men xz -9 (som f.eks. brukt til Linux-kjernetarballer) bruker mye mer enn bzip -9. (Og til og med xz -0 trenger mer enn gzip -9).

2: F21 System Wide Change: lbzip2 som standard implementering av bzip2

Kommentarer

• Eventuell kommentar til emnet feiltoleranse eller er det noe som ‘ alltid implementerte helt utenfor komprimeringsalgoritmer?
• @illumin É elastisitet kan ‘ ikke tilveiebringes uten å ofre kompresjonsforholdet. Det ‘ er et ortogonalt problem, og mens verktøy som Parchive eksisterer, gjør distribusjon av kjernen TCP ‘ feilhåndtering jobben akkurat som vel.
• @illumin É Feiltoleranse (forutsatt at du mener noe som ligner på par2) er ‘ t normalt ikke bekymring for å distribuere arkiver over Internett. Nedlastinger antas å være pålitelige nok (og du kan bare laste ned på nytt hvis den ble ødelagt). Kryptografiske hashes og signaturer blir ofte brukt, og de oppdager korrupsjon så vel som tukling. Det er kompressorer som gir større feiltoleranse, men på bekostning av kompresjonsforholdet. Ingen ser ut til å finne avveien verdt det for HTTP- eller FTP-nedlastinger.
• xz bruker MINDRE minne for å dekomprimere.
• @Mike Har det endret seg siden jeg skrev dette? Spesielt forklarer fotnote en minnebruk.

Først og fremst er dette spørsmålet ikke direkte relatert. til tar. Tar oppretter bare et ukomprimert arkiv, komprimeringen blir deretter brukt senere.

Gzip er kjent for å være relativt rask sammenlignet med LZMA2 og bzip2. Hvis hastighet betyr noe, gzip (spesielt den flertrådede implementeringen pigz ) er ofte et godt kompromiss mellom kompresjonshastighet og kompresjonsforhold. Selv om det finnes alternativer hvis hastighet er et problem (f.eks. LZ4).

Imidlertid, hvis et høyt kompresjonsforhold er ønsket, slår LZMA2 bzip2 i nesten alle aspekter. Kompresjonshastigheten er ofte tregere, men den dekomprimerer mye raskere og gir et mye bedre kompresjonsforhold på bekostning av høyere minnebruk.

Det er ikke mye grunn til å bruke bzip2 lenger, unntatt bakoverkompatibilitet. Videre ble LZMA2 utformet med tanke på multithreading, og mange implementeringer bruker som standard multicore-prosessorer (dessverre xz på Linux gjør ikke dette ennå). Dette er fornuftig siden klokkehastighetene ikke øker mer, men antall kjerner vil.

Det er flertrådede bzip2 implementeringer (f.eks. pbzip ), men de er ofte ikke installert som standard. Vær også oppmerksom på at flertrådet bzip2 bare virkelig lønne seg mens du komprimerer mens dekomprimering bruker en enkelt tråd hvis filen komprimeres ved hjelp av en enkelt tråd bzip2, i motsetning til LZMA2. Parallell bzip2 -varianter kan bare utnytte flere kjerner CPUer hvis filen ble komprimert ved hjelp av en parallell bzip2 -versjon, noe som ofte ikke er tilfelle.

Kommentarer

• Vel, noen tårer grok et z alternativ.
• » hastighet » gir et rotete svar. Du bør referere til kompresjonshastighet eller dekompresjonshastighet. Verken pixz, pbzi p2 eller pigz er installert som standard (eller brukes av tjære uten -I-flagget), men pixz og pbzip2 fremskynder komprimering og dekompresjon og pigz er bare for komprimering.
• @Tobu xz vil bli flertrådet som standard, så ingen pixz installasjon vil være nødvendig i fremtiden. På noen plattformer er xz threading allerede støttet. Mens bzip2 sannsynligvis aldri vil bli flertrådet siden formatet ikke var ‘ t designet med tanke på multitråding. Videre fremskynder pbzip2 bare dekompresjon hvis filen er komprimert ved hjelp av pbzip2 som ofte ikke er tilfelle.
• @Marco Jeg tror lbzip2 muliggjør parallell dekompresjon av filer selv om de ble komprimert med en ikke-parallell implementering (f.eks. Lager bzip2). Det er ‘ hvorfor jeg bruker lbzip2 over pbzip2. (Det ‘ er mulig dette har utviklet seg siden kommentaren din.)
• This makes sense since the clock speeds won't increase any more – hva? at ‘ ikke stemmer. innlegget ble laget i 2014, da Intel ga ut i3-4370 på 3,8 GHz. i 2017 ga Intel ut i7-8700K på 4,7 GHz. i 2018 ga de ut i9-9900K ved 5 GHz – og der ‘ er sannsynligvis cpus i 2015 & 2016 at ‘ mangler også på denne listen

LZMA2 er et komprimeringssystem mens gzip er ikke. Dette betyr at LZMA2 egner seg til multi-threading. Også, hvis korrupsjon oppstår i et arkiv, kan du vanligvis gjenopprette data fra påfølgende blokker med LZMA2, men du kan ikke gjøre dette med gzip. I praksis mister du hele arkivet med gzip etter den ødelagte blokken. Med et LZMA2-arkiv mister du bare filene som er berørt av de ødelagte blokkene. Dette kan være viktig i større arkiver med flere filer.

Kommentarer

• Dette er virkelig et veldig nyttig og viktig skille!
• Kan du sikkerhetskopiere disse påstandene med kilder? Jeg har ennå ikke sett et XZ-gjenopprettingsverktøy, og min kjente kilde hevder noe annet: nongnu.org/lzip/xz_inadequate.html

Kort svar : xz er mer effektiv når det gjelder kompresjonsforhold. Så det sparer diskplass og optimaliserer overføringen gjennom nettverket.
Du kan se dette Quick Benchmark for å oppdage forskjellen ved praktiske tester.

Kommentarer

• Linken er ødelagt.
• Ny lenke: catchchallenger.first -world.info/wiki/…