Linux / ext4, XFS e Btrfs: diferenças e critérios para escolher

Ao escolher entre ext4, XFS e Btrfs, compare o suporte da distribuição, os recursos necessários, os procedimentos de redimensionamento e recuperação antes de considerar qual é mais recente. Considere ext4 para administração conhecida e redução com o sistema desmontado, XFS para servidores com grande armazenamento e I/O concorrente, e Btrfs quando precisar de snapshots nativos, compressão e somas de verificação dos dados. Estes são pontos de partida: desempenho e adequação operacional ainda precisam ser verificados no seu ambiente.

Este artigo compara três sistemas de arquivos de disco local para PCs Linux e servidores de uso geral. Um sistema de arquivos organiza o conteúdo dos arquivos e informações como nomes, locais e permissões para que possam ser armazenados e recuperados. Se a relação entre discos, partições e pontos de montagem não estiver clara, comece com como discos, partições e sistemas de arquivos diferem.

ext4, XFS e Btrfs em resumo

Metadados são informações de gerenciamento, como a localização, tamanho e permissões de um arquivo. Journaling utiliza um registro de alterações para ajudar a restaurar a consistência do sistema de arquivos após uma falha inesperada; ele não substitui backups nem garante a preservação do conteúdo de cada arquivo. Copy-on-Write (CoW, cópia na gravação) grava conteúdos modificados em novo espaço e atualiza as referências a eles.

"Não" refere-se a um recurso fornecido pelo próprio sistema de arquivos. ext4 e XFS podem usar snapshots fornecidos pelo Gerenciador de Volumes Lógicos (LVM), um sistema de armazenamento ou uma plataforma de virtualização. Cópias de arquivos com compartilhamento de blocos, como os reflinks do XFS, também diferem de um snapshot de ponto no tempo de um sistema de arquivos inteiro. A linha de checksum diz respeito ao conteúdo comum dos arquivos; isso não significa que ext4 e XFS não tenham proteção de metadados.

ext4: administração familiar e redução offline

ext4, abreviação de Fourth Extended Filesystem, segue a família ext2 e ext3. O guia de instalação do Debian 13 afirma que o ext4 é selecionado por padrão na maioria dos casos. É um candidato útil a ser considerado junto com as ferramentas de instalação e recuperação da distribuição quando nenhum recurso especial é necessário. Ser o padrão não estabelece que ele seja sempre mais rápido ou mais seguro do que as alternativas. Consulte o guia oficial de instalação do Debian 13 para as escolhas da distribuição.

O modo padrão data=ordered do ext4 registra metadados no journal e ordena as gravações de dados relacionadas. Ele não grava uma segunda cópia de todo o conteúdo do arquivo no journal. Portanto, o fato de o sistema de arquivos montar após uma falha de energia não garante que o aplicativo tenha preservado suas últimas gravações. A documentação de administração do kernel Linux para ext4 explica esses modos.

A possibilidade de redução é uma distinção operacional importante. resize2fs pode ampliar um sistema de arquivos ext4 adequado enquanto está montado, mas para reduzir é necessário que esteja desmontado. Reduzir o sistema de arquivos raiz geralmente requer um ambiente de boot separado e tempo de inatividade. A ferramenta não redimensiona partições, portanto, o sistema de arquivos e seu armazenamento subjacente devem ser gerenciados separadamente. Verifique o manual do resize2fs em relação às condições de suporte do seu ambiente.

Por exemplo, se você espera redistribuir o espaço em disco entre o sistema operacional e áreas de dados posteriormente, compare o suporte à redução e o tempo de inatividade antes da instalação. Se snapshots de rollback forem o principal requisito, escolher apenas ext4 não os fornece: você também precisará projetar uma camada LVM ou outra de backup e snapshots.

XFS: servidores com grande capacidade de armazenamento e I/O concorrente

O XFS gerencia o armazenamento por meio de grupos de alocação e vale a pena ser avaliado para arquivos grandes e I/O concorrente de múltiplos trabalhos. O Red Hat Enterprise Linux (RHEL) 10 usa o XFS como seu sistema de arquivos local padrão. Se sua distribuição, ferramentas de armazenamento e procedimentos de recuperação já estiverem organizados em torno do XFS, esse suporte operacional também é um critério de seleção significativo. O guia de comparação e administração de sistemas de arquivos do RHEL 10 documenta seu suporte e casos de uso.

XFS cresce através de xfs_growfs enquanto montado. Espaço adicional deve primeiro estar disponível no dispositivo subjacente; ampliar um disco ou volume lógico sozinho não necessariamente aumenta o sistema de arquivos. Um plano de expansão deve distinguir as camadas de disco, partição, volume lógico e sistema de arquivos.

Evite descrever a redução do XFS como universalmente impossível ou geralmente disponível. As notas de lançamento do RHEL 10.0 descrevem a redução limitada dentro do último grupo de alocação como uma Prévia Tecnológica, desde que a faixa removida não contenha dados ou metadados alocados. Isto difere de um procedimento geral para reduzir para um tamanho arbitrário. Se a redução for importante, não baseie sua escolha nesta funcionalidade limitada: verifique o suporte de produção da distribuição ou planeje fazer backup e restaurar em um novo sistema de arquivos menor. Veja as notas do RHEL 10.0 sobre redução limitada do XFS e o manual xfs_growfs para as condições.

Inclua XFS entre os candidatos para um servidor de arquivos ou um servidor que armazena arquivos de dados grandes, mas não decida apenas pelo tamanho dos arquivos. Verifique a frequência de criação e exclusão de arquivos pequenos, concorrência, gravações síncronas e requisitos de latência em condições semelhantes ao serviço real.

Btrfs: combinando snapshots, compressão e somas de verificação

O Btrfs usa CoW e fornece subvolumes, snapshots, compressão transparente e checksums de dados e metadados. Uma soma de verificação (checksum) é calculada a partir do conteúdo armazenado e ajuda a detectar alterações quando esse conteúdo é lido novamente. O Fedora usa Btrfs por padrão em suas edições de desktop e spins, mas um padrão de desktop não implica suporte para todas as configurações de servidor ou disco. Veja a introdução oficial aos recursos do Btrfs e a orientação do Fedora sobre Btrfs.

Um subvolume é uma árvore de diretórios que pode ser gerenciada de forma independente dentro de um sistema de arquivos. Um snapshot inicialmente compartilha blocos de dados com sua origem e consome espaço adicional à medida que o conteúdo muda. Isso pode preservar um estado anterior à atualização, mas selecionar apenas o Btrfs não configura snapshots automáticos, retenção ou um menu de recuperação de inicialização. Verifique as ferramentas da distribuição e o layout do subvolume em conjunto.

Snapshots no mesmo disco não substituem um backup separado. A fonte e o snapshot dependem do mesmo armazenamento e blocos compartilhados, portanto a falha do dispositivo ou dano a um bloco compartilhado pode afetar ambos. Subvolumes aninhados não são incluídos recursivamente no snapshot de um pai. Aplicações que escrevem dados ativamente, como bancos de dados, também precisam de um backup da aplicação ou de um procedimento de pausa das gravações para obter um estado consistente. A documentação de subvolume e snapshot do Btrfs explica o escopo e as limitações do snapshot.

A detecção e a recuperação de erros são capacidades separadas. btrfs scrub verifica somas de verificação e outras informações, mas reparar conteúdos danificados requer uma cópia redundante íntegra e verificada do bloco afetado. Se uma configuração de disco único armazenar apenas uma cópia dos dados, uma soma de verificação pode revelar danos sem fornecer uma cópia da qual restaurá-los. Arquivos configurados com NOCOW também são uma exceção à verificação de dados por soma de verificação. A documentação oficial de scrub do Btrfs explica as condições de verificação e reparo.

A compressão pode reduzir o uso de espaço e E/S dependendo dos dados, mas vídeos ou arquivos já comprimidos podem ter poucos ganhos. Para imagens de máquinas virtuais (VM) ou bancos de dados com gravações frequentes, considere CoW, fragmentação e retenção de snapshots juntos. Aplicar NOCOW indiscriminadamente para desempenho também afeta checksums de dados e compressão. Veja a documentação de opções de montagem Btrfs para as interações.

Ao combinar discos, verifique cada perfil de RAID (Redundant Array of Independent Disks) separadamente. A introdução oficial do recurso descreve RAID5/6 como experimental e não pronto para produção. Não trate esses perfis como equivalentes aos outros; verifique as versões do kernel e das ferramentas junto com o estado do recurso Btrfs.

Qual sistema de arquivos é adequado para o seu ambiente?

Os seguintes critérios conectam as diferenças de recursos aos requisitos práticos. Eles não são uma classificação nem uma recomendação de configuração universal.

Se seu objetivo principal é reverter o sistema operacional após uma atualização falhada, verifique quais subvolumes a ferramenta de recuperação realmente restaura, assim como os recursos do Btrfs. O design difere dependendo se os dados do usuário devem permanecer atuais ou retornar ao mesmo ponto que o sistema operacional. Em um servidor cuja área de dados apenas cresce, o suporte da distribuição e os procedimentos de expansão e backup podem ser mais importantes do que a redução.

Condições que devem ser iguais em testes de desempenho

Um nome de sistema de arquivos sozinho não prediz a velocidade. Mesmo no mesmo SSD, criar muitos arquivos pequenos, ler um arquivo grande sequencialmente e realizar gravações síncronas em banco de dados podem produzir resultados diferentes. Testes curtos de cópia também podem ser fortemente afetados pelo cache de memória.

• Armazenamento: Use o mesmo SSD ou HDD, conexão, ocupação e condições de espaço livre.
• Carga de trabalho: Mantenha iguais os tamanhos e quantidades de arquivos, a proporção de leitura e gravação, o acesso sequencial ou aleatório e a concorrência.
• Recursos e configurações: Registre compressão, CoW, snapshots, criptografia e opções de montagem. Não compare recursos habilitados e desabilitados como se as condições fossem idênticas.
• Durabilidade: Mantenha iguais as gravações síncronas da aplicação e as políticas de cache do dispositivo. Enfraquecer as garantias de preservação de dados não é simplesmente uma melhoria de desempenho.
• Versões e medições: Registre as versões do kernel e das ferramentas de administração, e examine a latência e a variação de execução, bem como o throughput.

Para um servidor de armazenamento de logs, por exemplo, teste gravações adicionais de logs, rotação, compressão e backups ocorrendo ao mesmo tempo, em vez de copiar um arquivo grande. Pese a redução no uso de armazenamento da compressão contra seu custo de CPU. Se a vantagem medida for pequena, também considere o custo de migração e o risco de alterar o sistema de arquivos existente.

Verifique o formato atual e planeje quaisquer alterações

Inspecione o sistema atual sem alterá-lo

Em um sistema Linux típico, os seguintes comandos consultam dispositivos, montagens e capacidade. lsblk e findmnt vêm do util-linux; no GNU/Linux, df normalmente vem do coreutils. Esses comandos não criam nem alteram o formato do sistema de arquivos.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

Use lsblk para inspecionar relacionamentos de dispositivos e FSTYPE e findmnt para ver o tipo e as opções de montagem ativas do sistema de arquivos que contém o caminho raiz. df -hT / mostra o tipo e a capacidade desse sistema de arquivos. Para inspecionar outro caminho, use o diretório de dados real no lugar de /.

Por exemplo, se findmnt relatar xfs em FSTYPE, esse caminho está no XFS. O próprio FSTYPE de um disco pode estar em branco enquanto uma partição ou volume lógico mostra o formato. Um contêiner pode relatar overlay; não assuma que este seja o formato do disco do host. Se um lsblk mais antigo não suportar MOUNTPOINTS, use MOUNTPOINT. Consulte o manual lsblk e o manual findmnt para detalhes das opções.

Se o uso de espaço do Btrfs diferir das expectativas, btrfs filesystem usage pode mostrar dados, metadados e alocação de dispositivos juntos. Excluir arquivos pode não liberar imediatamente seu espaço se snapshots ainda fizerem referência aos dados. Em vez de confiar apenas nos totais de tamanho de diretório, aplique as explicações na documentação Btrfs sobre uso de espaço e redimensionamento.

Uma sequência de migração para um sistema de arquivos diferente

Executar o mkfs de outro formato em um sistema de arquivos existente não é uma conversão que preserve os dados. Um plano geral de migração é mais fácil de entender quando construído em torno de um novo destino e restauração verificada.

1. Identifique o dispositivo de origem, formato e ponto de montagem, verifique o suporte do aplicativo, faça backup para um armazenamento independente e verifique se a restauração funciona.
2. Prepare o sistema de arquivos de destino em um novo disco ou área disponível separadamente. Confirme novamente que é o destino vazio pretendido antes de formatar.
3. Obtenha dados consistentes durante o tempo de inatividade do serviço ou através do próprio mecanismo de backup do aplicativo. Copie ou restaure a propriedade necessária, permissões, Listas de Controle de Acesso (ACLs), atributos estendidos e links físicos. Não presuma que uma ferramenta que copia o conteúdo dos arquivos preserve todas essas informações.
4. Verifique arquivos e aplicativos no novo caminho e, em seguida, atualize /etc/fstab e as configurações do serviço usando o novo identificador do sistema de arquivos, ou UUID. Mover a raiz de um sistema operacional requer um procedimento separado que abranja o carregador de inicialização e o ambiente de inicialização inicial.
5. Após reiniciar, verifique montagens, serviços e permissões. Mantenha a fonte e o backup até que a troca seja verificada, para que, se ocorrerem problemas, você possa interromper gravações no novo destino e retornar ao original verificado e suas configurações. Inclua dados criados após a troca no plano de reversão.

A ordem das camadas também é importante ao redimensionar sem alterar os formatos. Normalmente, expanda o armazenamento subjacente antes de aumentar o sistema de arquivos; quando a redução é suportada, diminua o sistema de arquivos antes de reduzir seu armazenamento subjacente. O redimensionamento do Btrfs também não atualiza automaticamente a tabela de partições. Este princípio não é um procedimento completo: criptografia, LVM e RAID exigem cada um seus próprios passos suportados.

Use ferramentas apropriadas ao sistema de arquivos ao investigar erros. O e2fsck do ext4, xfs_repair do XFS e as ferramentas de verificação e recuperação do Btrfs não são intercambiáveis. Em particular, não use btrfs check --repair como uma primeira solução rotineira. A documentação oficial alerta contra isso sem orientação de um desenvolvedor ou usuário experiente. Revise fsck e precauções para verificações específicas do sistema de arquivos e o aviso do verificador Btrfs, e prepare backups e um plano de recuperação antes de fazer alterações.