Fedora 43: initrd será comprimido com Zstd por padrão – mais velocidade no boot e economia de espaço para todos

Escrito por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...

Zstd chega como padrão ao Fedora 43 e revoluciona o boot: mais rápido, menor e pronto para sistemas imutáveis.

Uma mudança silenciosa, porém poderosa, está prestes a transformar o tempo de inicialização dos sistemas baseados em Fedora. A partir da versão Fedora 43, o projeto pretende adotar o Zstd como algoritmo de compressão padrão para o initrd (ou initramfs), substituindo o tradicional xz nas imagens construídas com dracut. O objetivo? Reduzir o tempo de boot e economizar espaço em disco, especialmente nas partições mais sensíveis, como a /boot, que frequentemente é limitada em tamanho.

Essa decisão surge em meio a um contexto técnico cada vez mais voltado para sistemas imutáveis, como o Fedora CoreOS e o rpm-ostree, nos quais o gerenciamento de imagens é feito de forma atomizada e eficiente. A substituição do xz pelo zstd reflete não apenas uma melhoria pontual, mas uma reavaliação mais ampla de como otimizar a experiência do usuário, o desempenho do sistema e a escalabilidade em ambientes modernos de Linux.

Recomendação de leitura: Proposta do Fedora sobre a adoção do Zstd;

Otimização do boot: a proposta de Zstd como padrão para o initrd do Fedora

A proposta oficial, elaborada por Hristo Marinov e aprovada por membros influentes da comunidade como Timothée Ravier, define que todas as variantes do Fedora 43 passarão a utilizar zstd como método de compressão padrão no processo de geração do initrd via dracut. Essa alteração já foi integrada no Rawhide, a versão de desenvolvimento contínuo do Fedora, e está em testes para se tornar a nova norma nas futuras imagens de instalação e sistemas derivados.

Embora o zstd já seja amplamente utilizado em outras partes do Fedora (como na compressão de pacotes RPM), sua adoção como padrão para o initrd ainda era fragmentada. O dracut-ng, reescrito em Rust, já usa zstd por padrão. Com essa mudança no dracut.spec, a uniformização será finalmente implementada em toda a base do Fedora.

O que é initrd (ou initramfs) e por que sua compressão é vital para o boot?

O initrd (ou seu sucessor funcional initramfs) é um sistema de arquivos temporário que é carregado na memória logo após o Kernel Linux durante o processo de inicialização. Ele contém os módulos, scripts e utilitários essenciais que permitem ao sistema montar o root filesystem real e continuar o boot.

A compressão do initrd é crucial por dois motivos principais:

  • Redução de espaço na partição /boot, que costuma ser limitada em tamanho.
  • Velocidade de descompressão durante o boot, influenciando diretamente no tempo até o sistema estar operacional.

Por que Zstd? Vantagens em tamanho e velocidade de descompressão

O Zstd (Zstandard) é um algoritmo de compressão moderno, desenvolvido pelo Facebook (hoje Meta), que equilibra alta taxa de compressão com descompressão extremamente rápida. Comparado ao gzip e ao xz, os dois métodos historicamente usados no initrd, o zstd consegue:

  • Comprimir mais eficientemente que o gzip, ocupando menos espaço.
  • Descomprimir dezenas de vezes mais rápido que o xz, especialmente em núcleos de CPU modernos.
  • Ser configurado com níveis de compressão que equilibram performance e tamanho.

Desempenho comparado: Zstd vs. Gzip e Xz na compressão do initrd

Os dados apresentados na proposta incluem benchmarks reais que comparam as três opções:

AlgoritmoTamanho do initrdTempo de descompressão
gzip~62 MB~230 ms
xz~47 MB~1.110 ms
zstd~49 MB~120 ms

O zstd oferece quase o mesmo tamanho compacto do xz, mas com tempo de descompressão duas vezes mais rápido que o gzip e quase dez vezes mais rápido que o xz. Esses ganhos impactam diretamente a percepção do tempo de inicialização do sistema.

Metodologia dos benchmarks: testando a eficiência na prática

Os benchmarks foram realizados com imagens de initrd reais geradas por dracut em sistemas Fedora com Kernel recente, utilizando ferramentas como:

  • dnf repoquery para inspeção de dependências
  • dracut –force –compress para criar diferentes variações de imagens
  • grep e du -h para avaliar conteúdo e tamanho
  • bootchart e logs do systemd-analyze para avaliar o tempo de boot total

Essa abordagem prática garante que os resultados sejam representativos para sistemas reais em desktops, servidores ou ambientes virtualizados.

Resultados detalhados: ganhos de espaço e velocidade de descompressão

Além da tabela de comparação, destaca-se que o zstd consegue reduzir o tempo de inicialização em sistemas rpm-ostree em até 1 segundo em alguns casos, o que é um ganho significativo quando se considera o número de boots diários em servidores ou sistemas embarcados.

Na prática:

  • O espaço ocupado na /boot é reduzido entre 10% e 25%, dependendo do nível de compressão zstd escolhido.
  • O tempo de descompressão do initrd torna-se quase imperceptível, liberando o processador para continuar com o carregamento do sistema real.

Impacto na experiência do usuário: boots perceptivelmente mais rápidos

Para o usuário comum, isso se traduz em inicializações mais rápidas, menos travamentos no early-boot e maior eficiência em hardware com armazenamento mais lento (como SSDs SATA, eMMC ou cartões SD em dispositivos ARM).

Além disso, a velocidade do zstd permite que o sistema recupere a performance mesmo em situações onde há muito carregamento de drivers e módulos no initramfs, como em servidores com múltiplos dispositivos RAID, volumes LUKS ou redes complexas.

Contexto do Fedora: Zstd e a otimização de sistemas imutáveis

O Fedora tem investido fortemente em sistemas imutáveis com o rpm-ostree, como o Fedora Silverblue, Fedora Kinoite e o Fedora CoreOS. Nestes casos, a imagem do sistema é criada como um snapshot atômico que não muda dinamicamente após a instalação.

O uso de zstd no initrd se alinha a outras iniciativas de performance e confiabilidade nesses ambientes:

  • Redução de duplicação de dados no sistema base
  • Criação de imagens menores e mais rápidas para downloads e atualizações
  • Otimizações para bootc images e contenêineres com Podman Build, Docker Build

O desafio da partição /boot no Fedora CoreOS e rpm-ostree

Um problema comum enfrentado no Fedora CoreOS é a limitação de espaço em /boot, principalmente quando múltiplas versões de sistema e Kernel coexistem (ex: fallback, rollback, atualização atômica via rpm-ostree). Nesses cenários, um initrd menor significa:

  • Menor risco de falha na atualização automática
  • Menos necessidade de limpeza manual
  • Compatibilidade com o autopruning do sistema

Zstd: um passo à frente nas estratégias de otimização de imagem

Além do initrd, o zstd vem sendo cada vez mais adotado nas imagens de container, arquivos de log comprimidos, pacotes RPM e até nos bancos de dados de metadados de sistema. A uniformização com o zstd no boot é coerente com essa tendência ampla de padronização moderna.

Implementação e compatibilidade: a transição para Zstd no Fedora 43

A mudança está sendo realizada no pacote dracut.spec, que define a compressão padrão para zstd nas chamadas do dracut. Isso afeta:

  • Imagens geradas pela Anaconda durante a instalação
  • Ferramentas como o CoreOS Assembler
  • Scripts que usam o dracut diretamente em desktops ou servidores

Sistemas que ainda utilizam s390x ou ambientes legados continuarão com suporte a gzip, garantindo compatibilidade reversa.

O que muda para desenvolvedores e usuários existentes

Usuários que constroem seus próprios initrds (via dracut --compress) devem estar atentos para a mudança de comportamento padrão. No entanto, é possível sobrescrever o algoritmo manualmente com:

dracut --compress xz --force

Desenvolvedores de spins customizados devem atualizar seus scripts de build para refletir a nova compressão, se necessário.

Como testar a nova compressão Zstd no seu sistema Fedora

No Fedora Rawhide, já é possível gerar initrds com zstd utilizando:

sudo dracut --force --compress zstd

Depois, reinicie o sistema e use systemd-analyze para comparar os tempos de boot com outras versões. Você pode também verificar o tamanho do novo initrd com:

ls -lh /boot/initramfs-$(uname -r).img

Além da compressão: outras estratégias para reduzir o tamanho do initramfs

A adoção do zstd é uma peça de um quebra-cabeça maior que envolve:

  • Carregamento dinâmico de módulos apenas quando necessário
  • Separação de componentes não críticos (como firmwares, debug)
  • Exclusão de binários redundantes no initrd
  • Uso de Ignition, Afterburn, e NetworkManager para inicialização condicional

Essas técnicas combinadas oferecem uma base sólida para um boot mais enxuto, rápido e robusto.

Carregamento dinâmico de componentes e separação de binários

Uma das propostas futuras é tornar o initramfs modular, permitindo que componentes como suporte a LUKS, RAID, NFS ou iSCSI sejam adicionados sob demanda, ao invés de incluídos por padrão. Isso reduziria ainda mais o tamanho das imagens e aceleraria seu carregamento.

O futuro das otimizações de boot no Fedora

Além da compressão zstd, o Fedora está investindo em:

  • dracut-ng (reescrito em Rust, mais seguro e rápido)
  • bootc images para boot de containers
  • Tang-bound disk encryption com desbloqueio de disco em rede
  • Cincinatti upgrade graph para atualização segura de imagens

Essas iniciativas apontam para um futuro em que o boot será mais confiável, modular e eficiente, independentemente do tipo de dispositivo ou cenário de uso.

Conclusão: Fedora 43 e Zstd – um compromisso com a performance e eficiência do Linux

A decisão de adotar o zstd como compressão padrão do initrd no Fedora 43 representa mais que uma troca de algoritmo: é um passo estratégico em direção a um sistema operacional mais rápido, moderno e adaptado às exigências da computação atual. Em um mundo onde cada segundo conta e cada megabyte importa, o Fedora mostra que continua liderando com decisões técnicas inteligentes, baseadas em dados e voltadas para o futuro do Linux.

Compartilhe este artigo