Hvorfor skifter tjærearkivformater til xz-komprimering for at erstatte bzip2, og hvad med gzip?

Til distribution arkiver over internettet, er følgende ting generelt en prioritet:

1. Kompressionsforhold (dvs. hvor lille kompressoren laver dataene);
2. Dekompressionstid (CPU-krav) ;
3. Hukommelseskrav til dekompression og
4. Kompatibilitet (hvor bredt dekomprimeringsprogrammet er spredt)

Kompressionshukommelse & CPU-kravene er ikke meget vigtigt, fordi du kan bruge en stor hurtig maskine til det, og du behøver kun at gøre det en gang.

Sammenlignet med bzip2 har xz et bedre kompressionsforhold og lavere (bedre) dekompressionstid. Det kræver dog – ved de kompressionsindstillinger, der typisk bruges – mere hukommelse for at dekomprimere ^[1] og er noget mindre udbredt. Gzip bruger mindre hukommelse end nogen af disse.

Så arkiverne i både gzip og xz-format er sendt, så du kan vælge:

• Behov for at dekomprimere på en maskine med meget begrænset hukommelse (< 32 MB): gzip. Givet, ikke meget sandsynligt, når vi taler om kernekilder.
• Behov for at dekomprimere minimale tilgængelige værktøjer: gzip
• Vil du spare downloadtid og / eller båndbredde: xz

Der er ikke rigtig en realistisk kombination af faktorer, der får dig til at vælge bzip2. Så det udfases.

Jeg kiggede på kompressionssammenligninger i et blogindlæg . Jeg forsøgte ikke at replikere resultaterne, og jeg formoder, at noget af det er ændret (for det meste forventer jeg, at xz er forbedret, da det er det nyeste.)

(Der er nogle specifikke scenarier, hvor en god bzip2-implementering kan være at foretrække frem for xz: bzip2 kan komprimere en fil med mange nuller og genom-DNA-sekvenser bedre end xz. Nyere versioner af xz har nu en (valgfri) bloktilstand, der tillader data genopretning efter korruption og parallel kompression og [teoretisk] dekompression. Tidligere tilbød kun bzip2 disse. ^[2] Dog er ingen af disse relevante for kernedistribution)

1: I arkivstørrelse er xz -3 omkring bzip -9. Derefter bruger xz mindre hukommelse til at dekomprimere. Men xz -9 (som f.eks. brugt til Linux-kernetarballs) bruger meget mere end bzip -9. (Og endda xz -0 har brug for mere end gzip -9).

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

Kommentarer

• Enhver kommentar til emnet fejltolerance eller er det noget, som ‘ altid implementeres fuldstændigt uden for komprimeringsalgoritmer?
• @illumin É elastisitet kan ‘ ikke tilvejebringes uden at kompromittere kompressionsforholdet. Det ‘ er et ortogonalt problem, og mens der findes værktøjer som Parchive, gør distributionen af kernen TCP ‘ s fejlhåndtering job som godt.
• @illumin É Fejltolerance (forudsat at du mener noget der ligner par2) er ikke ‘ t er normalt ikke bekymring med at distribuere arkiver over internettet. Downloads antages at være pålidelige nok (og du kan bare downloade igen, hvis den blev ødelagt). Kryptografiske hashes og signaturer bruges ofte, og de opdager korruption såvel som manipulation. Der er kompressorer, der giver større fejltolerance, dog på bekostning af kompressionsforholdet. Ingen ser ud til, at afvejningen er værd for HTTP- eller FTP-downloads.
• xz bruger MINDRE hukommelse til at dekomprimere.
• @Mike Har det ændret sig, siden jeg skrev dette? Fodnote 1 forklarer især hukommelsesforbrug.

Først og fremmest er dette spørgsmål ikke direkte relateret til tar. Tjære opretter bare et ukomprimeret arkiv, komprimeringen anvendes derefter senere.

Gzip er kendt for at være relativt hurtig sammenlignet med LZMA2 og bzip2. Hvis hastighed betyder noget, gzip (især den multitrådede implementering pigz ) er ofte et godt kompromis mellem kompressionshastighed og kompressionsforhold. Selvom der er alternativer, hvis hastighed er et problem (f.eks. LZ4).

Men hvis et højt kompressionsforhold ønskes, slår LZMA2 bzip2 i næsten alle aspekter. Kompressionshastigheden er ofte langsommere, men dekomprimeres meget hurtigere og giver et meget bedre kompressionsforhold på bekostning af højere hukommelsesforbrug.

Der er ikke meget grund til at bruge bzip2 længere, undtagen bagudkompatibilitet. Desuden blev LZMA2 designet med multithreading i tankerne, og mange implementeringer bruger som standard multicore-CPUer (desværre xz på Linux gør det endnu ikke). Dette giver mening, da urets hastigheder ikke stiger mere, men antallet af kerner vil.

Der er multitrådede bzip2 implementeringer (f.eks. pbzip ), men de er ofte ikke installeret som standard. Bemærk også, at flertrådet bzip2 kun virkelig betale sig under komprimering mens dekompression bruger en enkelt tråd, hvis filen komprimeres ved hjælp af en enkelt gevind bzip2, i modsætning til LZMA2. Parallel bzip2 -varianter kan kun udnytte multicore-CPUer, hvis filen blev komprimeret ved hjælp af en parallel bzip2 -version, hvilket ofte ikke er tilfældet.

Kommentarer

• Nå, nogle tårer grok en z mulighed.
• ” hastighed ” giver et forvirret svar, du skal henvise til komprimeringshastighed eller dekompressionshastighed. Hverken pixz, pbzi p2 eller pigz er installeret som standard (eller bruges af tjære uden -I-flag), men pixz og pbzip2 fremskynder kompression og dekompression og pigz er kun til komprimering.
• @Tobu xz vil blive multitrådet som standard, så der kræves ingen pixz installation i fremtiden. På nogle platforme understøttes xz threading allerede. Mens bzip2 sandsynligvis aldrig vil blive multitrådet, da formatet ikke var ‘ t designet med multithreading i tankerne. Desuden fremskynder pbzip2 kun dekompression, hvis filen er komprimeret ved hjælp af pbzip2 hvilket ofte ikke er tilfældet.
• @Marco Jeg tror, lbzip2 muliggør parallel dekompression af filer, selvom de blev komprimeret med en ikke-parallel implementering (f.eks. Stock bzip2). Derfor ‘ hvorfor jeg bruger lbzip2 frem for pbzip2. (Det ‘ er muligt, dette har udviklet sig siden din kommentar.)
• This makes sense since the clock speeds won't increase any more – hvad? at ‘ ikke er rigtigt. indlægget blev lavet i 2014, da Intel udgav i3-4370 ved 3,8 GHz. i 2017 udgav Intel i7-8700K ved 4,7 GHz. i 2018 frigav de i9-9900K ved 5 GHz – og der er ‘ sandsynligvis cpus i 2015 & 2016 at ‘ mangler også på denne liste

LZMA2 er et blokkomprimeringssystem, mens gzip er ikke. Dette betyder, at LZMA2 egner sig til multi-threading. Også, hvis der opstår korruption i et arkiv, kan du generelt gendanne data fra efterfølgende blokke med LZMA2, men du kan ikke gøre dette med gzip. I praksis mister du hele arkivet med gzip efter den ødelagte blok. Med et LZMA2-arkiv mister du kun de filer, der er berørt af de beskadigede blokke. Dette kan være vigtigt i større arkiver med flere filer.

Kommentarer

• Dette er faktisk en meget nyttig og vigtig forskel!
• Kan du sikkerhedskopiere disse krav med kilder? Jeg har endnu ikke set et XZ-gendannelsesværktøj, og min kendte kilde hævder ellers: nongnu.org/lzip/xz_inadequate.html

Kort svar : xz er mere effektiv med hensyn til kompressionsforhold. Så det sparer diskplads og optimerer overførslen gennem netværket.
Du kan se dette Quick Benchmark for at opdage forskellen ved praktiske tests.

Kommentarer

• Linket er brudt.
• Nyt link: catchchallenger.first -world.info/wiki/…