Por que os formatos de arquivo tar estão mudando para a compactação xz para substituir o bzip2 e o gzip?

Para distribuição arquivos na Internet, as seguintes coisas são geralmente uma prioridade:

1. Taxa de compressão (ou seja, quão pequenos o compressor torna os dados);
2. Tempo de descompressão (requisitos de CPU) ;
3. Requisitos de memória de descompressão; e
4. Compatibilidade (a extensão do programa de descompressão)

Memória de compactação & Os requisitos de CPU não são muito importante, porque você pode usar uma máquina grande e rápida para isso, e você só precisa fazer isso uma vez.

Comparado ao bzip2, xz tem uma taxa de compressão melhor e um tempo de descompressão menor (melhor). No entanto, nas configurações de compactação normalmente usadas, requer mais memória para descompactar ^[1] e é um pouco menos difundido. Gzip usa menos memória do que qualquer um deles.

Portanto, os arquivos nos formatos gzip e xz são publicados, permitindo que você escolha:

• Precisa descompactar em uma máquina com muito memória limitada (< 32 MB): gzip. Dado, não é muito provável quando se fala sobre fontes de kernel.
• Necessidade de descompactar ferramentas mínimas disponíveis: gzip
• Deseja economizar tempo de download e / ou largura de banda: xz

Não existe realmente uma combinação realista de fatores que o levaria a escolher o bzip2. Portanto, está sendo eliminado.

Eu olhei as comparações de compactação em uma postagem do blog . Não tentei replicar os resultados e suspeito que alguns deles mudaram (principalmente, espero que xz tenha melhorado, por ser o mais recente.)

(Existem alguns cenários específicos onde uma boa implementação de bzip2 pode ser preferível a xz: bzip2 pode comprimir um arquivo com muitos zeros e sequências de DNA do genoma melhor do que xz. Versões mais recentes de xz agora têm um modo de bloco (opcional) que permite dados recuperação após o ponto de corrupção e compactação paralela e [em teoria] descompactação. Anteriormente, apenas o bzip2 oferecia isso. ^[2] No entanto, nenhum deles é relevante para a distribuição do kernel)

1: No tamanho do arquivo, xz -3 está em torno de bzip -9. Então xz usa menos memória para descompactar. Mas xz -9 (como, por exemplo, usado para tarballs do kernel do Linux) usa muito mais do que bzip -9. (E até xz -0 precisa de mais do que gzip -9).

2: F21 Mudança em todo o sistema: lbzip2 como implementação bzip2 padrão

Comentários

• Qualquer comentário sobre o tópico de tolerância a falhas ou é algo que ‘ s sempre implementado completamente fora dos algoritmos de compressão?
• @illumin É a resiliência não pode ‘ ser fornecida sem sacrificar a taxa de compressão. É ‘ um problema ortogonal e, embora existam ferramentas como o Parchive, para distribuir o kernel TCP ‘ o tratamento de erros faz o trabalho exatamente como bem.
• @illumin É A tolerância a falhas (supondo que você queira dizer algo semelhante a par2) não ‘ t normalmente um preocupação com a distribuição de arquivos pela Internet. Os downloads são considerados confiáveis o suficiente (e você pode apenas baixá-los novamente se estiver corrompido). Hashes criptográficos e assinaturas são freqüentemente usados e detectam corrupção e adulteração. Existem compressores que proporcionam maior tolerância a falhas, embora ao custo da taxa de compressão. Ninguém parece achar que vale a pena fazer download de HTTP ou FTP.
• xz usa MENOS memória para descompactar.
• @Mike Isso mudou desde que escrevi isso? Em particular, a nota de rodapé um explica o uso de memória.

Em primeiro lugar, esta questão não está diretamente relacionada para tar. Tar apenas cria um arquivo descompactado, a compressão é então aplicada mais tarde.

O Gzip é conhecido por ser relativamente rápido quando comparado ao LZMA2 e ao bzip2. Se a velocidade for importante, gzip (especialmente a implementação multithread pigz ) geralmente é um bom meio-termo entre a velocidade de compressão e a taxa de compressão. Embora existam alternativas se a velocidade for um problema (por exemplo, LZ4).

No entanto, se uma taxa de compressão alta for desejada, LZMA2 bate bzip2 em quase todos os aspectos. A velocidade de compactação costuma ser mais lenta, mas é descompactada muito mais rápido e oferece uma taxa de compactação muito melhor ao custo de um maior uso de memória.

Não há muitos motivos para usar bzip2 mais, exceto de compatibilidade com versões anteriores. Além disso, LZMA2 foi projetado com multithreading em mente e muitas implementações por padrão fazem uso de CPUs multicore (infelizmente xz no Linux ainda não faz isso). Isso faz sentido, uma vez que as velocidades de clock “não aumentarão mais, mas o número de núcleos aumentará.

Existem implementações bzip2 multithread (por exemplo, pbzip ), mas geralmente não são instalados por padrão. Observe também que multithread bzip2 realmente compensa ao compactar , enquanto a descompactação usa uma única thread se o arquivo foi compactado usando uma única thread bzip2, em contraste com LZMA2. Paralela bzip2 as variantes só podem aproveitar CPUs multicore se o arquivo foi compactado usando uma versão bzip2 paralela, o que geralmente não é o caso.

Comentários

• Bem, alguns tars grok uma z opção.
• ” velocidade ” torna a resposta confusa, você deve se referir à velocidade de compressão ou velocidade de descompressão. Nem pixz, pbzi p2 ou pigz são instalados por padrão (ou usados pelo tar sem o sinalizador -I), mas pixz e pbzip2 aceleram a compactação e descompressão e pigz é apenas para compactação.
• @Tobu xz será multithreaded por padrão, então nenhuma pixz instalação será necessária no futuro. Em algumas plataformas xz já há suporte para threading. Considerando que bzip2 provavelmente nunca será multithread, já que o formato não foi ‘ projetado com multithreading em mente. Além disso, pbzip2 apenas acelera a descompactação se o arquivo tiver sido compactado usando pbzip2, o que geralmente não é o caso.
• @Marco Eu acredito que lbzip2 permite a descompactação paralela de arquivos, mesmo se eles foram compactados com uma implementação não paralela (por exemplo, bzip2 de estoque). É por ‘ que uso lbzip2 em vez de pbzip2. (É ‘ possível que isso tenha evoluído desde seu comentário.)
• This makes sense since the clock speeds won't increase any more – o quê? que ‘ não é bem verdade. a postagem foi feita em 2014, quando a Intel lançou o i3-4370 a 3,8GHz. em 2017, a Intel lançou o i7-8700K a 4,7 GHz. em 2018, eles lançaram o i9-9900K a 5 GHz – e há ‘ s provavelmente cpus em 2015 & 2016 que ‘ também está faltando nesta lista

LZMA2 é um sistema de compressão de blocos, enquanto gzip não é. Isso significa que o LZMA2 se presta a multithreading. Além disso, se ocorrer corrupção em um arquivo, geralmente você pode recuperar dados de blocos subsequentes com LZMA2, mas não pode fazer isso com gzip. Na prática, você perde todo o arquivo com gzip após o bloco corrompido. Com um arquivo LZMA2, você só perde o (s) arquivo (s) afetado (s) pelo (s) bloco (s) corrompido (s). Isso pode ser importante em arquivos maiores com vários arquivos.

Comentários

• Esta é uma distinção muito útil e importante, de fato!
• Você pode fazer o backup dessas afirmações com as fontes? Ainda não vi uma ferramenta de recuperação XZ e minha fonte conhecida afirma o contrário: nongnu.org/lzip/xz_inadequate.html

Resposta curta : xz é mais eficiente em termos de taxa de compressão. Assim, ele economiza espaço em disco e otimiza a transferência pela rede.
Você pode ver este Quick Benchmark para descobrir a diferença por meio de testes práticos.

Comentários

• O link está quebrado.
• Novo link: catchchallenger.first -world.info/wiki/…