Egyre több tar archívum tömörítéshez használja az LZMA2 alapú xz formátumot a hagyományos bzip2(bz2) tömörítés. Valójában a kernel.org késői “ Viszlát bzip2 ” bejelentést tett, 2013. december 27. , jelezve, hogy a kernelforrások ettől a ponttól mind a tar.gz, mind a tar.xz formátumban megjelennek – és a weboldal főoldalán kínált a tar.xz fájlban található.

Van-e valamilyen konkrét ok arra, hogy miért történik ez, és mi a jelentősége a gzip ebben az összefüggésben?

Válasz

Terjesztéshez archívumok az interneten keresztül, a következő dolgok általában prioritást élveznek:

  1. Tömörítési arány (azaz, hogy a kompresszor milyen kicsi adatokat készít);
  2. Dekompressziós idő (CPU követelmények) ;
  3. Dekompressziós memória követelményei; és
  4. Kompatibilitás (milyen kiterjedt a dekompressziós program)

Tömörítési memória & A CPU-követelmények nem” t nagyon fontos, mert ehhez nagy, gyors gépet használhat, és ezt csak egyszer kell megtennie.

A bzip2-hez képest az xz jobb tömörítési arányú és alacsonyabb (jobb) dekompressziós idővel rendelkezik. Ennek ellenére – a jellemzően használt tömörítési beállításoknál – több memória szükséges a [1] kicsomagolásához, és kissé kevésbé elterjedt. A Gzip kevesebb memóriát használ, mint bármelyik.

Tehát mind a gzip, mind az xz formátumú archívumokat közzéteszik, így kiválaszthatja:

  • Dekompressziót kell végrehajtani egy olyan gépen, ahol nagyon korlátozott memória (< 32 MB): gzip. Adott, nem túl valószínű, ha a kernelforrásokról beszélünk.
  • A rendelkezésre álló minimális eszközök dekompresszálásának szükségessége: gzip
  • Szeretné megtakarítani a letöltési időt és / vagy a sávszélességet: xz

Nincs olyan tényezők reális kombinációja, amelyek ráveszik a bzip2 kiválasztására. Ezért fokozatosan megszűnik.

A tömörítési összehasonlításokat blogbejegyzésben néztem. Nem próbáltam megismételni az eredményeket, és gyanítom, hogy némelyik megváltozott (leginkább azt gondolom, hogy a xz javult, mivel a legújabb.)

(Vannak olyan speciális esetek, amikor egy jó bzip2 megvalósítás előnyösebb lehet, mint az xz: a bzip2 jobban képes tömöríteni a sok nullával és genom DNS-szekvenciával rendelkező fájlt, mint az xz. Az xz újabb verzióiban már van (opcionális) blokk mód, amely lehetővé teszi az adatokat helyreállítás a korrupció, a párhuzamos tömörítés és [elméletileg] a dekompresszió után. Korábban csak a bzip2 kínálta ezeket. [2] Ezek azonban egyik sem relevánsak a kernelterjesztés szempontjából)

1: Archív méretben a xz -3 bzip -9 körül van. Ezután az xz kevesebb memóriát használ a kicsomagoláshoz. De (például, például a Linux kernel-tárfájlokhoz használt) sokkal többet használ, mint a bzip -9. (És még xz -0 több kell, mint gzip -9).

2: F21 Rendszer széles változás: lbzip2 alapértelmezett bzip2 megvalósításként

Megjegyzések

  • Bármely megjegyzés a témához hibatűrés vagy valami olyan, amelyet ‘ mindig a tömörítési algoritmusokon kívül valósított meg?
  • @illumin É rugalmasság ‘ nem biztosítható a tömörítési arány feláldozása nélkül. ‘ ortogonális probléma, és bár léteznek olyan eszközök, mint a Parchive, a rendszermag TCP terjesztésére a terjesztéshez ‘ s a hibakezelés ugyanúgy elvégzi a munkát jól.
  • @illumin É A hibatűrés (feltételezve, hogy a par2-hez hasonlóra gondolsz) általában nem ‘ az archívumok interneten keresztüli terjesztésével kapcsolatos aggodalom. A letöltéseket feltételezzük, hogy elég megbízhatóak (és csak akkor töltheti le újra, ha sérült volt). Gyakran használnak kriptográfiai kivonatokat és aláírásokat, amelyek észlelik a korrupciót és a manipulációt is. Vannak olyan kompresszorok, amelyek nagyobb hibatűrést biztosítanak, bár a tömörítési arány árán. Úgy tűnik, senki sem találja meg a kompromisszumot a HTTP vagy FTP letöltéseknél.
  • Az xz LESS memóriát használ a kicsomagoláshoz.
  • @Mike Megváltozott azóta, hogy ezt írtam? Különösen az első lábjegyzet magyarázza a memóriahasználatot.

Válasz

Először is, ez a kérdés nem kapcsolódik közvetlenül hogy tar. Tar csak egy tömörítetlen archívumot hoz létre, majd a tömörítést később alkalmazzák.

A Gzip az LZMA2-hez és a bzip2-hez képest viszonylag gyors. Ha a sebesség számít, gzip (különösen a többszálú megvalósítás pigz ) gyakran jó kompromisszum a tömörítési sebesség és a tömörítési arány között. Bár vannak alternatívák, ha a sebesség kérdés (pl. LZ4).

Ha azonban magas tömörítési arányra van szükség, az LZMA2 szinte minden szempontból legyőz bzip2. A tömörítési sebesség gyakran lassabb, de sokkal gyorsabban dekompresszálódik, és sokkal jobb tömörítési arányt biztosít a magasabb memóriahasználat árán.

Nincs sok ok a bzip2 többé, kivéve a visszafelé kompatibilitást. Ezenkívül az LZMA2-et a többszálas szálak szem előtt tartásával tervezték meg, és alapértelmezés szerint sok megvalósítás többmagos CPU-kat használ (sajnos a Linuxon xz ezt még nem teszi meg). Ennek van értelme, mivel az órajelek nem fognak tovább növekedni, de a magok száma megnő.

Többszálas bzip2 megvalósítások vannak (pl. pbzip ), de gyakran alapértelmezés szerint nincsenek telepítve. Vegye figyelembe azt is, hogy a többszálú bzip2 Csak akkor térül meg igazán, amikor tömörít en, míg a dekompresszió egyetlen szálat használ, ha a fájlt egyetlen szálon bzip2 tömörítették, ellentétben az LZMA2-vel. = “7582bb06c1”>

változatok csak akkor használhatják a többmagos CPU-kat, ha a fájlt párhuzamosbzip2verzióval tömörítették, ami gyakran nem így van.

Megjegyzések

  • Nos, néhány kátrány grok egy z opciót.
  • ” speed ” zavaros választ ad, a tömörítési sebességre vagy a dekompresszió sebességére kell utalni. Sem pixz, sem pbzi A p2 vagy a pigz alapértelmezés szerint telepítve van (vagy a tar használja az -I jelző nélkül), de a pixz és a pbzip2 felgyorsítja a tömörítést és a dekompressziót, a pigz pedig csak tömörítésre szolgál.
  • @Tobu alapértelmezés szerint többszálas lesz, ezért a jövőben nincs szükség pixz telepítésre. Néhány platformon a xz szálak már támogatottak. Míg a bzip2 valószínűtlen, hogy valaha is többszálas lesz, mivel a formátumot nem ‘ t tervezték többszálas szálak szem előtt tartásával. Ezenkívül a pbzip2 csak akkor gyorsítja a dekompressziót, ha a fájlt pbzip2 segítségével tömörítették, ami gyakran nem így van.
  • @Marco Úgy gondolom, hogy az lbzip2 lehetővé teszi a fájlok párhuzamos dekompresszióját akkor is, ha azokat nem párhuzamos megvalósítással tömörítették (például stock bzip2). Ezért ‘ ezért használom az lbzip2-t a pbzip2 helyett. (Lehetséges, hogy ‘ ez a kommentje óta fejlődött.)
  • This makes sense since the clock speeds won't increase any more – mi? hogy ‘ nem egészen igaz. a bejegyzés 2014-ben készült, amikor az Intel kiadta az i3-4370-et 3,8 GHz-en. 2017-ben az Intel kiadta a i7-8700K -et 4,7 GHz-en. 2018-ban kiadták az i9-9900K-ot 5 GHz-en – és valószínűleg ‘ s valószínűleg 2015-ben cpus & 2016 ‘ hiányzik ebből a listából is

Válasz

Az LZMA2 blokktömörítő rendszer, míg a gzip nem az. Ez azt jelenti, hogy az LZMA2 többszálas menettel rendelkezik. Továbbá, ha egy archívumban korrupció történik, akkor az LZMA2-vel általában visszaállíthatja az adatokat a következő blokkokból, de ezt nem tudja megtenni a gzip segítségével. A gyakorlatban az egész archívumot elveszíti a sérült blokkot követő gzip-el. Az LZMA2 archívummal csak a sérült blokk (ok) által érintett fájl (oka) t veszítheti el. Ez fontos lehet a nagyobb, több fájlt tartalmazó archívumokban.

Megjegyzések

  • Ez valóban nagyon hasznos és fontos megkülönböztetés!
  • Támogathatja ezeket az állításokat forrásokkal? Még nem láttam egy XZ helyreállító eszközt, és ismert forrásom másként állítja: nongnu.org/lzip/xz_inadequate.html

Válasz

Rövid válasz : Az xz a tömörítési arány szempontjából hatékonyabb. Tehát lemezterületet takarít meg és optimalizálja a hálózaton keresztüli átvitelt.
Láthatja ezt a gyors benchmarkot , hogy gyakorlati tesztekkel fedezze fel a különbséget.

Megjegyzések

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük