Converter BZ2 para GZ

O bzip2 teve uma boa década: entre mais ou menos 1998 e 2010 era a resposta óbvia quando o gzip não comprimia o bastante, e muita coisa publicada nessa janela ainda é `.tar.bz2` — conjuntos de dados de referência, tarballs de kernel, depósitos científicos, o fixture que uma suíte de testes baixa a cada execução desde antes de qualquer pessoa atual do time entrar.

O arquivo em si não é o problema. O problema é que algo o descompacta numa rotina, e a descompressão do bzip2 é lenta o bastante para aparecer no log de um build. Ninguém vai recortar de novo o lançamento original — o jeito prático é recomprimir localmente em algo que abre rápido e cachear isso.

Os dois formatos descomprimem de jeitos estruturalmente diferentes, e a diferença não é questão de implementação. A saída do gzip é construída copiando bytes literais e copiando trechos anteriores de uma janela de 32 KB — o laço interno é basicamente movimentação de memória, e o hardware moderno é ótimo nisso.

O bzip2 precisa inverter uma transformada de Burrows–Wheeler para cada bloco de até 900 KB: reconstruir a ordem original a partir de uma permutação ordenada, uma passagem espalhada e nada amigável ao cache antes de qualquer byte de saída ficar pronto, mais desfazer as camadas de move-to-front e Huffman ao redor. É computação de verdade, não movimentação de dados, e nenhum ajuste transforma isso em velocidade de memória.

Espere que o GZ fique maior, e espere que a margem dependa inteiramente do conteúdo. O bzip2 enxerga até 900 KB de contexto de cada vez, contra 32 KB do gzip, então em texto, logs, CSV, código-fonte e XML ele encontra repetição que o gzip não alcança.

Em outros conteúdos não há diferença que valha medir. Um arquivo bzip2 de JPEGs, PNGs, MP3s, MP4s ou um banco de dados já comprimido tem pouca compressão para começo de conversa — a redundância já foi removida por esses formatos antes de o arquivo entrar na compactação —, então recomprimir como gzip custa quase nada e traz todo o ganho de velocidade.

Um fluxo gzip guarda o nome do arquivo original no cabeçalho. Um fluxo bzip2 não guarda nada assim — nem nome, nem caminho, nenhuma pista sobre o conteúdo. Essa assimetria normalmente é uma curiosidade, e ela produziu um defeito real neste conversor.

A conversão precisa desembrulhar o TAR de dentro de um archive comprimido, e a primeira versão do código decidia se tinha achado um olhando o nome do arquivo. De um GZ isso funcionava, porque o gzip lembrava `output.tar`. De um BZ2 ou um XZ o mesmo tarball chegava chamado `input`, a checagem não detectava, e a conversão produzia um archive com um arquivo opaco só em vez dos trinta que entraram. A correção foi forçar o tipo tar em vez de inferir pelo nome.

Onipresença é a segunda metade do argumento desta conversão, e é fácil subestimar. DEFLATE é a compressão dentro do `Content-Encoding: gzip` do HTTP, dentro do PNG, dentro de um ZIP e dentro de um objeto do Git. Toda linguagem relevante já tem isso na biblioteca padrão — sem dependência para adicionar.

Bzip2 é uma biblioteca separada que precisa estar presente, e num contêiner mínimo, num runtime travado ou numa função de nuvem, muitas vezes não está. Gzip é uma codificação de conteúdo HTTP registrada, e bzip2 nunca foi.

Vale nomear o que se abre mão, não só o que se ganha. O bzip2 comprime cada bloco de forma independente, então um dano num bloco não destrói automaticamente tudo depois dele, e ferramentas de recuperação conseguem percorrer um arquivo corrompido e salvar os blocos intactos. Um fluxo gzip não tem essa estrutura — um bit invertido no meio do caminho costuma encerrar o arquivo ali.

Quanto isso importa depende de onde o arquivo mora. Num sistema de arquivos moderno com checksums ou num armazenamento de objetos que verifica o que devolve, importa pouco. Num único disco envelhecendo guardando a única cópia de algo insubstituível, importa mais — e nesse caso a resposta certa não é nenhum dos dois formatos, é um backup de verdade com integridade por arquivo.

Se o archive está sendo guardado, e não lido com frequência, gzip é o destino errado e XZ é o certo — vai comprimir os mesmos conteúdos consideravelmente melhor que o bzip2 e ainda descomprimir mais rápido. O leitor desta página não é essa pessoa, mas muita gente convertendo um archive bzip2 é, e vale avisar.

O teste é simples: conte quantas vezes o archive é descompactado. Com frequência, por máquinas, numa etapa que alguém espera — gzip. Raramente, por uma pessoa, de um armazenamento que cobra por gigabyte-mês — XZ. O único caso em que o bzip2 deveria ficar é uma máquina com pouquíssima memória.

No nosso servidor, não no seu aparelho. A maioria das ferramentas deste site converte localmente e diz isso claramente; archives são uma das exceções, porque o trabalho precisa de 7-Zip e gzip como programas de verdade. O arquivo viaja por conexão criptografada até um contêiner que roda esses programas e que não tem acesso próprio à internet.

O job recebe um diretório de trabalho num sistema de arquivos baseado em memória, apagado assim que o job termina, e é encerrado depois de sessenta segundos — o que é uma restrição real aqui, já que o bzip2 é lento para descomprimir. O plano gratuito aceita 25 MB por arquivo enviado, e antes de extrair qualquer coisa o archive é questionado sobre quanto afirma expandir; acima de 2 GB é recusado direto.

Esta conversão só vale a pena se os números disserem que sim, e conferir isso leva dois minutos: cronometre a extração do archive bzip2, cronometre a do gzipado, e compare os dois tamanhos. Se o archive é pequeno ou o pipeline o descompacta uma vez por mês, a economia é ruído.

Guarde o bzip2 original até que algo tenha realmente consumido o novo arquivo com sucesso. Não porque a conversão tem perdas — não tem, cada membro sai byte a byte —, mas porque o tarball é reconstruído em vez de passado direto, então ordem dos membros, datas e bits de permissão podem mudar.