Coraz więcej tar archiwów użyj formatu xz opartego na LZMA2 do kompresji zamiast tradycyjnego bzip2(bz2) kompresja. W rzeczywistości kernel.org opublikował późne ogłoszenie „ Good-bye bzip2 ” , 27 grudnia 2013 r. , wskazując, że źródła jądra będą od tego momentu wydawane zarówno w formacie tar.gz, jak i tar.xz – a na stronie głównej witryny , co jest bezpośrednio oferowane jest w tar.xz.

Czy istnieją jakieś konkretne powody wyjaśniające, dlaczego tak się dzieje i jakie jest znaczenie gzip w tym kontekście?

Odpowiedź

Do dystrybucji archiwa w Internecie, na ogół priorytetem są następujące rzeczy:

  1. Współczynnik kompresji (tj. jak mały kompresor tworzy dane);
  2. Czas dekompresji (wymagania procesora) ;
  3. Wymagania dotyczące pamięci dekompresji; oraz
  4. Zgodność (jak bardzo rozpowszechniony jest program dekompresyjny)

Pamięć kompresji & Nie ma wymagań dotyczących procesora bardzo ważne, ponieważ możesz użyć do tego dużej, szybkiej maszyny i musisz to zrobić tylko raz.

W porównaniu do bzip2, xz ma lepszy współczynnik kompresji i niższy (lepszy) czas dekompresji. Jednak – przy typowych ustawieniach kompresji – wymaga więcej pamięci do dekompresji [1] i jest nieco mniej rozpowszechniona. Gzip zużywa mniej pamięci niż którykolwiek z nich.

Tak więc, zarówno archiwa w formacie gzip, jak i xz są wysyłane, co pozwala wybrać:

  • Konieczność dekompresji na maszynie z bardzo ograniczona pamięć (< 32 MB): gzip. Biorąc pod uwagę, mało prawdopodobne, gdy mówimy o źródłach jądra.
  • Należy zdekompresować minimalne dostępne narzędzia: gzip
  • Chcesz zaoszczędzić czas pobierania i / lub przepustowość: xz

Tak naprawdę nie ma realistycznej kombinacji czynników, które skłoniłyby cię do wybrania bzip2. Więc to jest wycofywane.

Przyjrzałem się porównaniom kompresji w poście na blogu . Nie próbowałem odtworzyć wyników i podejrzewam, że niektóre z nich uległy zmianie (głównie, spodziewam się, że xz poprawił się, ponieważ jest najnowszy).

(Istnieją określone scenariusze, w których dobra implementacja bzip2 może być lepsza niż xz: bzip2 może kompresować plik z dużą ilością zer i sekwencjami DNA genomu lepiej niż xz. Nowsze wersje xz mają teraz (opcjonalny) tryb blokowy, który umożliwia odzyskiwanie po punkcie zepsucia i równoległej kompresji i [teoretycznie] dekompresji. Wcześniej tylko bzip2 oferował je. [2] Jednak żadne z nich nie jest istotne dla dystrybucji jądra)

1: W rozmiarze archiwum xz -3 wynosi około bzip -9. Wtedy xz zużywa mniej pamięci do dekompresji. Ale xz -9 (jak np. używane do paczek z jądrem Linuksa) zużywa znacznie więcej niż bzip -9. (A nawet xz -0 potrzebuje więcej niż gzip -9).

2: F21 Zmiana w całym systemie: lbzip2 jako domyślna implementacja bzip2

Komentarze

  • Wszelkie komentarze na temat odporność na błędy czy jest to coś, co ' jest zawsze implementowane całkowicie poza algorytmami kompresji?
  • @illumin É nie można zapewnić ' elastyczności bez poświęcania współczynnika kompresji. Jest to ' problem ortogonalny i chociaż istnieją narzędzia takie jak Parchive, do dystrybucji jądra TCP ' obsługa błędów działa tak samo, jak cóż.
  • @illumin É Tolerancja błędów (zakładając, że masz na myśli coś podobnego do par2) nie jest ' t normalnie troska o rozpowszechnianie archiwów w Internecie. Zakłada się, że pobieranie jest wystarczająco niezawodne (i możesz po prostu pobrać je ponownie, jeśli było uszkodzone). Często używane są kryptograficzne skróty i podpisy, które wykrywają zarówno uszkodzenia, jak i manipulacje. Istnieją sprężarki, które zapewniają większą odporność na awarie, chociaż kosztem stopnia sprężania. Wydaje się, że nikt nie znalazł kompromisu w przypadku pobierania przez HTTP lub FTP.
  • xz używa MNIEJ pamięci do dekompresji.
  • @Mike Czy zmieniło się to od czasu, gdy to napisałem? W szczególności przypis pierwszy wyjaśnia użycie pamięci.

Odpowiedź

Po pierwsze, to pytanie nie jest bezpośrednio powiązane do tar. Tar po prostu tworzy nieskompresowane archiwum, kompresja jest następnie stosowana później.

Wiadomo, że Gzip jest stosunkowo szybki w porównaniu z LZMA2 i bzip2. Jeśli liczy się szybkość, gzip (zwłaszcza implementacja wielowątkowa pigz ) jest często dobrym kompromisem między szybkością kompresji a współczynnikiem kompresji. Chociaż istnieją alternatywy, jeśli szybkość jest problemem (np. LZ4).

Jednak jeśli pożądany jest wysoki współczynnik kompresji, LZMA2 bije bzip2 prawie w każdym aspekcie. Szybkość kompresji jest często wolniejsza, ale dekompresuje znacznie szybciej i zapewnia znacznie lepszy współczynnik kompresji kosztem większego zużycia pamięci.

Nie ma powodu, aby używać bzip2 już więcej, z wyjątkiem kompatybilności wstecznej. Ponadto LZMA2 został zaprojektowany z myślą o wielowątkowości i wiele implementacji domyślnie korzysta z procesorów wielordzeniowych (niestety xz w Linuksie jeszcze tego nie robi). Ma to sens, ponieważ szybkości zegara już nie wzrosną, ale liczba rdzeni wzrośnie.

Istnieją wielowątkowe implementacje bzip2 (np. pbzip ), ale często nie są instalowane domyślnie. Pamiętaj też, że wielowątkowe bzip2 naprawdę opłaca się tylko przy kompresji , podczas gdy dekompresja wykorzystuje pojedynczy wątek, jeśli plik został skompresowany przy użyciu jednowątkowego bzip2, w przeciwieństwie do LZMA2. = „7582bb06c1”>

mogą wykorzystywać procesory wielordzeniowe tylko wtedy, gdy plik został skompresowany przy użyciu równoległej wersjibzip2, co często nie ma miejsca.

Komentarze

  • Cóż, niektóre tars grok a z opcja.
  • ” prędkość ” to niejasna odpowiedź, powinieneś odnieść się do szybkości kompresji lub prędkości dekompresji. Ani pixz, pbzi p2 lub pigz są instalowane domyślnie (lub używane przez tar bez flagi -I), ale pixz i pbzip2 przyspieszają kompresję i dekompresję, a pigz służy tylko do kompresji.
  • @Tobu xz będzie domyślnie wielowątkowy, więc w przyszłości nie będzie wymagana żadna pixz instalacja. Na niektórych platformach xz wątki są już obsługiwane. Natomiast bzip2 prawdopodobnie nigdy nie będzie wielowątkowy, ponieważ format nie został ' zaprojektowany z myślą o wielowątkowości. Ponadto pbzip2 przyspiesza dekompresję tylko wtedy, gdy plik został skompresowany przy użyciu pbzip2, co często nie ma miejsca.
  • @Marco Uważam, że lbzip2 pozwala na równoległą dekompresję plików, nawet jeśli zostały skompresowane w nierównoległej implementacji (np. Bzip2). Właśnie dlatego ' używam lbzip2 zamiast pbzip2. (Możliwe, że ' zmieniło się to od czasu Twojego komentarza.)
  • This makes sense since the clock speeds won't increase any more – co? że ' nie jest do końca prawdą. post powstał w 2014 roku, kiedy Intel wypuścił i3-4370 z częstotliwością 3,8 GHz. w 2017 roku Intel wypuścił i7-8700K na 4,7 GHz. w 2018 roku wydali i9-9900K z częstotliwością 5 GHz – i tam ' prawdopodobnie cpus w 2015 r. & 2016, ' też brakuje na tej liście

Odpowiedź

LZMA2 to system kompresji bloków, podczas gdy gzip nie jest. Oznacza to, że LZMA2 nadaje się do wielowątkowości. Ponadto, jeśli w archiwum wystąpi uszkodzenie, możesz ogólnie odzyskać dane z kolejnych bloków za pomocą LZMA2, ale nie możesz tego zrobić za pomocą gzip. W praktyce tracisz całe archiwum za pomocą gzip po uszkodzonym bloku. W przypadku archiwum LZMA2 tracisz tylko pliki, na które wpływają uszkodzone bloki. Może to być ważne w przypadku większych archiwów z wieloma plikami.

Komentarze

  • To jest rzeczywiście bardzo przydatne i ważne rozróżnienie!
  • Czy możesz poprzeć te twierdzenia źródłami? Nie widziałem jeszcze narzędzia do odzyskiwania XZ, a moje znane źródło twierdzi, że jest inaczej: nongnu.org/lzip/xz_inadequate.html

Odpowiedź

Krótka odpowiedź : xz jest bardziej wydajny pod względem współczynnika kompresji. Dzięki temu oszczędza miejsce na dysku i optymalizuje transfer przez sieć.
Możesz zobaczyć ten Szybki test porównawczy , aby odkryć różnicę w praktycznych testach.

Komentarze

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *