Varför byter tjärarkivformat till xz-komprimering för att ersätta bzip2 och vad sägs om gzip?

För distribution arkiv över Internet är följande saker i allmänhet en prioritet:

1. Kompressionsförhållande (dvs. hur liten kompressorn gör data);
2. Dekompressionstid (CPU-krav) ;
3. Krav på dekomprimeringsminne och
4. Kompatibilitet (hur spridd dekompressionsprogrammet är)

Kompressionsminne & CPU-kraven är inte mycket viktigt, för du kan använda en stor snabb maskin för det, och du behöver bara göra det en gång.

Jämfört med bzip2 har xz ett bättre kompressionsförhållande och lägre (bättre) dekompressionstid. Det kräver dock mer minne vid komprimeringsinställningarna för att dekomprimera ^[1] och är något mindre utbrett. Gzip använder mindre minne än någon av dem.

Så, arkiv i både gzip- och xz-format läggs upp, så att du kan välja:

• Behöver dekomprimera på en maskin med mycket begränsat minne (< 32 MB): gzip. Givet, inte mycket troligt när man talar om kärnkällor.
• Behöver dekomprimera minimala tillgängliga verktyg: gzip
• Vill spara nedladdningstid och / eller bandbredd: xz

Det finns egentligen inte en realistisk kombination av faktorer som får dig att välja bzip2. Så det fasas ut.

Jag tittade på kompressionsjämförelser i ett blogginlägg . Jag försökte inte replikera resultaten och jag misstänker att något av det har förändrats (mestadels förväntar jag mig att xz har förbättrats, eftersom det är det senaste.)

(Det finns några specifika scenarier där en bra bzip2-implementering kan vara att föredra framför xz: bzip2 kan komprimera en fil med många nollor och genom-DNA-sekvenser bättre än xz. Nyare versioner av xz har nu ett (valfritt) blockläge som tillåter data återhämtning efter korruption och parallell komprimering och [i teorin] dekompression. Tidigare erbjöd bara bzip2 dessa. ^[2] Men inget av dessa är relevant för kärnfördelning)

1: I arkivstorlek är xz -3 runt bzip -9. Då använder xz mindre minne för att dekomprimera. Men xz -9 (som t.ex. används för Linux-kärntärbollar) använder mycket mer än bzip -9. (Och även xz -0 behöver mer än gzip -9).

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

Kommentarer

• Eventuella kommentarer om ämnet feltolerans eller är det något som ’ alltid har implementerat helt utanför komprimeringsalgoritmer?
• @illumin É fjädringsförmåga kan ’ inte tillhandahållas utan att kompromissa med kompressionsförhållandet. Det ’ är ett ortogonalt problem, och medan verktyg som Parchive finns, för att distribuera kärnans TCP ’ s felhantering gör jobbet precis som väl.
• @illumin É Feltolerans (förutsatt att du menar något som liknar par2) är inte ’ t är normalt inte oro över att distribuera arkiv över Internet. Nedladdningar antas vara tillräckligt tillförlitliga (och du kan bara ladda ner om den var skadad). Kryptografiska haschar och signaturer används ofta och de upptäcker korruption såväl som manipulering. Det finns kompressorer som ger större feltolerans, men till kostnaden för kompressionsförhållandet. Ingen verkar hitta avvägningen värt det för HTTP- eller FTP-nedladdningar.
• xz använder MINDRE minne för att dekomprimera.
• @Mike Har det förändrats sedan jag skrev det här? Fotnot 1 förklarar särskilt minnesanvändning.

För det första är denna fråga inte direkt relaterad till tar. Tar skapar bara ett okomprimerat arkiv, komprimeringen tillämpas sedan senare.

Gzip är känt för att vara relativt snabbt jämfört med LZMA2 och bzip2. Om hastighet betyder något, gzip (särskilt den flertrådade implementeringen pigz ) är ofta en bra kompromiss mellan kompressionshastighet och kompressionsförhållande. Även om det finns alternativ om hastighet är ett problem (t.ex. LZ4).

Men om ett högt kompressionsförhållande önskas slår LZMA2 bzip2 i nästan alla aspekter. Kompressionshastigheten är ofta långsammare, men dekomprimeras mycket snabbare och ger ett mycket bättre kompressionsförhållande till kostnaden för högre minnesanvändning.

Det finns inte mycket anledning att använda bzip2 längre, utom bakåtkompatibilitet. Dessutom designades LZMA2 med multithreading i åtanke och många implementeringar använder som standard multicore-processorer (tyvärr xz på Linux gör det ännu inte). Detta är vettigt eftersom klockhastigheterna inte kommer att öka mer men antalet kärnor kommer att.

Det finns flertrådade bzip2 implementeringar (t.ex. pbzip ), men de är ofta inte installerade som standard. Observera att flertrådade bzip2 lönar sig bara verkligen under komprimering medan dekompression använder en enda tråd om filen komprimeras med en enda tråd bzip2, till skillnad från LZMA2. Parallell bzip2 -varianter kan endast utnyttja flerkärniga processorer om filen komprimeras med en parallell bzip2 -version, vilket ofta inte är fallet.

Kommentarer

• Några tårar grokar ett z -alternativ.
• ” hastighet ” ger ett rörigt svar, du bör hänvisa till komprimeringshastighet eller dekompressionshastighet. Varken pixz, pbzi p2 eller pigz är installerat som standard (eller används av tjära utan flaggan -I), men pixz och pbzip2 påskyndar komprimering och dekompression och pigz är bara för komprimering.
• @Tobu xz kommer att vara flertrådade som standard så ingen pixz installation krävs i framtiden. På vissa plattformar stöds xz trådning redan. Medan bzip2 sannolikt aldrig kommer att bli multitrådat eftersom formatet inte var ’ t utformat med multithreading i åtanke. Dessutom, pbzip2 påskyndar bara dekompressionen om filen har komprimerats med pbzip2 vilket ofta inte är fallet.
• @Marco Jag tror att lbzip2 möjliggör parallell dekomprimering av filer även om de komprimeras med en icke-parallell implementering (t.ex. lager bzip2). Det är ’ varför jag använder lbzip2 över pbzip2. (Det är ’ om detta har utvecklats sedan din kommentar.)
• This makes sense since the clock speeds won't increase any more – vad? att ’ inte är helt sant. inlägget gjordes 2014, när Intel släppte i3-4370 vid 3,8 GHz. 2017 släppte Intel i7-8700K vid 4,7 GHz. 2018 släppte de i9-9900K vid 5 GHz – och där ’ är troligen cpus 2015 & 2016 att ’ saknas också i denna lista

LZMA2 är ett blockkomprimeringssystem medan gzip är inte. Detta innebär att LZMA2 lämpar sig för multi-threading. Om korruption uppstår i ett arkiv kan du också generellt återställa data från efterföljande block med LZMA2 men du kan inte göra det med gzip. I praktiken förlorar du hela arkivet med gzip efter det skadade blocket. Med ett LZMA2-arkiv förlorar du bara filerna som påverkas av de skadade blocken. Detta kan vara viktigt i större arkiv med flera filer.

Kommentarer

• Detta är verkligen en mycket användbar och viktig åtskillnad!
• Kan du säkerhetskopiera dessa påståenden med källor? Jag har ännu inte sett ett XZ-återställningsverktyg, och min kända källa hävdar något annat: nongnu.org/lzip/xz_inadequate.html

Kort svar : xz är effektivare när det gäller kompressionsförhållande. Så det sparar diskutrymme och optimerar överföringen via nätverket.
Du kan se detta Quick Benchmark för att upptäcka skillnaden genom praktiska tester.

Kommentarer

• Länken är trasig.
• Ny länk: catchchallenger.first -world.info/wiki/…