Sistemas de Arquivos no Linux: ext4, XFS e Btrfs na prática para servidores, containers e discos NVMe

Para servidor Linux de produção, ext4 nem sempre é a melhor escolha. Eu sei que isso bate de frente com o hábito de muita gente, porque ext4 virou o “padrão seguro” por anos. Mas, quando você olha para workloads reais — VM densa, banco PostgreSQL, storage de container, volume em NVMe, snapshots, necessidade de expansão online — a resposta muda rápido. O melhor sistema de arquivos no Linux depende do tipo de carga, do comportamento esperado em falha e do quanto você quer automatizar recuperação, expansão e auditoria do storage.

Eu vou ser direto: se você administra Linux e DevOps com alguma seriedade, não dá para tratar sistema de arquivos como detalhe. Ele afeta boot, performance, observabilidade, backup, estratégia de partição, provisionamento via Terraform/Ansible, e até o desenho do seu pipeline de restore. E, sim, sistemas de arquivos no Linux são um tema que separa quem “instala servidor” de quem realmente projeta infraestrutura.

ext4: o velho conhecido que ainda faz muito sentido

O ext4 continua sendo a escolha mais pragmática quando você quer previsibilidade e baixa surpresa operacional. Eu uso ext4 com frequência em VMs pequenas, hosts utilitários, root filesystem de máquinas que precisam subir rápido e ambientes em que o administrador quer algo estável, bem documentado e fácil de recuperar com ferramentas padrão.

A principal força do ext4 está na maturidade. Ele é robusto, tem journaling consistente, lida bem com apagões, e o ecossistema ao redor dele é extremamente maduro. Se você precisa reinstalar, montar em rescue mode, inspecionar blocos e corrigir inconsistências com e2fsck, a história é simples. Isso importa quando o ambiente é heterogêneo, quando você herda VM antiga, ou quando o time de SRE prefere reduzir variáveis de suporte.

# Criando filesystem ext4 em uma partição dedicada
mkfs.ext4 -L data-app /dev/nvme1n1p1

# Montagem com opções comuns para servidor
mount -o noatime,commit=30 /dev/nvme1n1p1 /data

# Persistência no /etc/fstab usando UUID
blkid /dev/nvme1n1p1

Um ponto que eu considero prático no ext4: ele se comporta muito bem em root filesystem e em volumes que não exigem recursos avançados de snapshot nativo. Para servidores de aplicação, bastam opções simples como noatime para cortar escrita desnecessária. Em discos SATA ou SSD sem exigências especiais, a operação fica fácil e o tuning costuma ser suficiente.

Mas há limites claros. O ext4 não entrega snapshots nativos, não faz checksums de dados e não oferece o mesmo nível de recursos modernos de gerenciamento online que Btrfs traz. Em cenários de storage mais sofisticado, ele vira uma base sólida, porém pouco expressiva. É uma escolha excelente quando você quer confiabilidade sem invenção. Não é a melhor opção quando o requisito inclui elasticidade e introspecção do volume em tempo real.

Quando ext4 vence sem esforço

• Root filesystem de VPS, cloud instance ou VM legada.
• Volumes de aplicação que exigem simplicidade operacional.
• Ambientes com equipe pequena e pouca tolerância a mudança de ferramenta.
• Recuperação previsível com utilitários clássicos do ecossistema Linux.

XFS: a escolha que eu prefiro para volumes grandes e crescimento online

Se o seu cenário envolve dados grandes, crescimento contínuo e I/O pesado, XFS entra com mais autoridade que ext4. Eu gosto de XFS em diretórios de dados de banco, repositórios de artefatos, payloads de observabilidade e arquivos grandes em geral. A razão é simples: ele foi feito para escalar bem com arquivos grandes e para manter desempenho consistente em workloads paralelizáveis.

XFS brilha em volumes grandes, especialmente quando o storage cresce depois da implantação inicial. A expansão online é um dos motivos pelos quais ele aparece tanto em ambientes corporativos e em servidores que precisam absorver aumento de capacidade sem downtime. Se você junta isso com LVM, a combinação fica muito forte para operação diária.

# Criando um XFS em uma LV já provisionada
mkfs.xfs -L logs-prod /dev/vg0/lv_logs

# Montando com noatime e relatime ajustado para workloads de leitura
mount -o noatime /dev/vg0/lv_logs /var/log

# Expandindo filesystem XFS depois de crescer a LV
lvextend -L +200G /dev/vg0/lv_logs
xfs_growfs /var/log

O detalhe que muita gente ignora: XFS não reduz tamanho online. Isso precisa entrar no seu desenho de capacidade. Se sua política de storage depende de shrink frequente, ele deixa de ser atraente. Mas, se o fluxo real é crescer volume com frequência e raramente encolher, o XFS é objetivo e eficiente. Em ambientes DevOps isso é comum: você cria volumes para logs, filas, artifacts ou bases com folga inicial e vai ampliando conforme consumo. O XFS encaixa bem nesse modelo.

Outro fator forte é o comportamento sob paralelismo. Em servidores com múltiplos processos escrevendo simultaneamente, XFS costuma se comportar com mais consistência do que ext4 em cenários mais pesados. Eu não venderia isso como regra universal de benchmark, porque a pilha inteira importa — controlador, cache, scheduler, NVMe, latência do hypervisor, padrão de acesso — mas na prática XFS costuma ser uma escolha madura quando o volume vai receber escrita intensa e arquivos grandes.

Onde XFS costuma ser a decisão certa

Eu colocaria XFS como padrão em três casos bem específicos: diretórios de dados de bancos com expansão planejada, storage de logs centralizados e ambientes de virtualização com arquivos de imagem grandes. Se o requisito é manter o volume crescendo sem parar a aplicação, XFS combina muito com a operação.

# Exemplo de /etc/fstab para XFS em ambiente de produção
UUID=3a2f7d5a-4e3f-4dbe-8c1a-7a1d2f9c8b11 /var/lib/postgresql xfs defaults,noatime 0 0

Btrfs: forte demais para ignorar, mas não é o padrão que eu colocaria em tudo

Se você quer snapshots nativos, subvolumes, compressão transparente e uma camada de gestão mais moderna, Btrfs entra no jogo com argumentos reais. Eu uso Btrfs com mais cautela do que ext4 e XFS, mas seria desonesto tratá-lo como experimento. Ele resolve problemas concretos de operação, especialmente em estações de trabalho Linux, hosts de desenvolvimento, pequenos ambientes de laboratório, storage com snapshots frequentes e cenários em que rollback rápido vale ouro.

O recurso de subvolume muda o desenho da máquina. Em vez de pensar apenas em partições, você começa a organizar o filesystem como estrutura de armazenamento com pontos de montagem lógicos. Isso ajuda muito em ambientes onde você quer snapshot de /var, rollback de /home e isolamento de diretórios críticos. E quando entra compressão, especialmente com zstd, a economia de espaço pode ser bem útil em SSD e NVMe com datasets mistos.

# Criando filesystem Btrfs e subvolumes
mkfs.btrfs -L lab /dev/sdb1
mount /dev/sdb1 /mnt
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
umount /mnt

# Montagem com subvolumes
mount -o subvol=@,compress=zstd,noatime /dev/sdb1 /mnt
mkdir -p /mnt/home
mount -o subvol=@home,compress=zstd,noatime /dev/sdb1 /mnt/home

Os snapshots são o ponto mais sedutor. Antes de uma alteração em massa — atualização de pacote, troca de kernel, deploy arriscado, mudança de layout de diretório — você cria snapshot e volta atrás em segundos, sem depender de restore de backup tradicional. Em laboratório isso é ouro. Em workstation de desenvolvimento também. Em produção, eu só colocaria Btrfs quando a equipe conhece o comportamento da tecnologia e já tem rotina de monitoramento e recuperação bem amarrada.

Porque Btrfs exige disciplina. Balance, scrub, atenção ao estado do pool, planejamento de RAID interno, tudo isso entra na rotina. Ele não é difícil por natureza, mas ele é menos “invisível” do que ext4. Se o time não vai olhar estado de saúde do filesystem e entender o impacto de snapshots, a adoção vira dívida operacional. O melhor filesystem não é o mais bonito no papel; é o que seu time sabe operar às 3 da manhã sem improviso.

Comandos que você precisa conhecer se usar Btrfs

# Ver uso real de subvolumes e espaço
btrfs filesystem usage /mnt
btrfs subvolume list /mnt

# Scrub para validar integridade
btrfs scrub start -Bd /mnt

# Balance em caso de distribuição desigual de blocos
btrfs balance start /mnt

Comparando ext4, XFS e Btrfs sem romantizar

Se eu tivesse que resumir a decisão de forma operacional, seria assim: ext4 é a aposta mais segura para simplicidade; XFS é a opção mais forte para volumes grandes e crescimento; Btrfs é o filesystem mais interessante para snapshots, compressão e organização flexível do armazenamento. Isso não significa que um “substitui” o outro. Significa que cada um resolve uma classe de problema diferente.

Em servidores de banco de dados, eu tendo a preferir XFS para diretórios de dados e ext4 para root se a máquina for simples. Se a stack usa LVM e precisa de gestão de capacidade objetiva, XFS ganha terreno. Se você administra um lab de Kubernetes em bare metal ou VMs de teste, Btrfs pode reduzir muito o atrito de snapshots e rollback de ambientes. Cada decisão precisa casar com a estratégia de automação.

# Exemplo de verificação de tipo de filesystem
findmnt -no FSTYPE,TARGET / /var/lib/docker /var/lib/postgresql
lsblk -f

Eu gosto de tratar o filesystem como parte da arquitetura, não como pós-configuração. Isso significa incluir a escolha no Terraform, nos templates de cloud-init, nos papéis do Ansible e na documentação de restore. Se você provisiona uma VM com ext4 e depois descobre que precisa de snapshots frequentes, vai acabar remendando o desenho. Se provisiona XFS para um storage que nunca será reduzido, ótimo. Se quer rollback de ambiente de laboratório, Btrfs entra com vantagem objetiva.

Automação: o filesystem certo já nasce no provisionamento

Eu não gosto de ver decisão de filesystem feita manualmente no console depois que a VM já subiu. Isso vira inconsistência entre ambientes. O ideal é deixar a escolha codificada. Em infraestrutura como código, o tipo de filesystem faz parte do estado desejado.

Com cloud-init, por exemplo, você já consegue formatar e montar volumes durante o boot. O mesmo raciocínio vale para Ansible. Abaixo, um exemplo de playbook simples para criar um filesystem XFS em um disco dedicado, montar e persistir no fstab:

- hosts: storage_nodes
 become: true
 tasks:
 - name: Create XFS filesystem
 filesystem:
 fstype: xfs
 dev: /dev/nvme1n1
 opts: -L data01

 - name: Create mount point
 file:
 path: /data
 state: directory
 mode: "0755"

 - name: Mount filesystem
 mount:
 path: /data
 src: LABEL=data01
 fstype: xfs
 opts: noatime
 state: mounted

Se você usa Terraform para provisionar VMs, o filesystem entra no user_data ou em uma etapa de configuração pós-boot. Não deixe isso para a mão do operador. O ponto não é só padronizar. É reproduzir a mesma arquitetura em staging, produção e disaster recovery.

# Exemplo de pós-provisionamento com shell script idempotente
#!/usr/bin/env bash
set -euo pipefail

DEV=/dev/nvme1n1
MNT=/var/lib/registry
FSTYPE=xfs
LABEL=registry

if ! blkid "$DEV" >/dev/null 2>&1; then
 mkfs.$FSTYPE -L "$LABEL" "$DEV"
fi

mkdir -p "$MNT"
UUID=$(blkid -s UUID -o value "$DEV")
if ! grep -q "$UUID" /etc/fstab; then
 echo "UUID=$UUID $MNT $FSTYPE defaults,noatime 0 0" >> /etc/fstab
fi
mount -a

O detalhe que quase todo mundo subestima: alinhamento com o workload

Container runtime, banco de dados, CI runner, logs, artefatos, home de usuário, snapshot de laboratório — cada um desses perfis pede comportamento diferente. Docker e containerd tendem a gostar de filesystem com boa resposta a metadados e múltiplos arquivos pequenos. Bancos gostam de latência previsível e journaling confiável. Artefatos de CI podem se beneficiar de compressão e limpeza rápida. Logs centralizados pedem crescimento contínuo e manutenção simples.

Se o seu nó Kubernetes usa /var/lib/containerd ou /var/lib/docker em ext4, tudo bem, desde que o volume seja bem dimensionado e o padrão de escrita não exija snapshots locais. Se você quer brincar com snapshots do ambiente de build ou com rollback de uma instância de laboratório, Btrfs começa a ficar sedutor. Se o storage de dados vai crescer sem parar, XFS faz mais sentido que ext4 para muita gente.

Eu também olho para o custo operacional de troubleshooting. Em ext4, a recuperação é quase sempre direta. Em XFS, você precisa entender melhor o comportamento do filesystem e aceitar que certas operações são pensadas para crescimento. Em Btrfs, o administrador precisa olhar estado de subvolumes, uso de espaço real e equilíbrio do pool. Cada escolha traz um tipo de trabalho. Não existe almoço grátis, só trade-off técnico explícito.

Uma matriz curta que eu uso na prática

• Root de servidor simples: ext4.
• Volume de dados com crescimento constante: XFS.
• Lab com snapshot e rollback: Btrfs.
• Filesystem para operação conservadora: ext4.
• Filesystem para expansão online em volume grande: XFS.
• Filesystem para gestão moderna de subvolumes: Btrfs.

Comandos de inspeção que eu deixo no kit de bolso

Antes de decidir qualquer coisa, eu olho o que está montado, como está alinhado e o que o kernel está reportando. Isso evita opinião baseada em hábito.

# Identificar tipo de filesystem e ponto de montagem
findmnt -o SOURCE,TARGET,FSTYPE,OPTIONS

# Ver blocos e labels
lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINTS

# Checar uso e inode em ext4/xfs
df -hT
df -ih

# Ver integridade e saúde em Btrfs
btrfs filesystem df /mnt
btrfs device stats /mnt

Também vale lembrar que o tipo de filesystem não existe isolado. Ele conversa com LVM, RAID, camada de virtualização, cache do storage e política de backup. Eu não escolho XFS só porque “é bom”; eu escolho XFS quando o plano inclui crescer LVM online e manter o serviço ativo. Eu não escolho Btrfs só por moda; eu escolho quando snapshots e subvolumes realmente reduzem risco operacional.

Se você usa systemd, isso fica ainda mais interessante. Mount units, automação de fstab, dependências de serviços, boot ordering. Um filesystem mal escolhido atrasa boot, complica recovery e cria ruído em incident response. Um filesystem bem escolhido desaparece da discussão. E esse, para mim, é o melhor sinal de arquitetura correta.

Escolha por perfil: o que eu faria no seu lugar

Para um servidor de produção com pouca margem para surpresa, eu manteria ext4 no root e XFS nos volumes de dados grandes. Essa combinação é conservadora, fácil de operar e encaixa bem em boa parte das infraestruturas Linux que eu vejo no dia a dia. Se o ambiente tem forte dependência de snapshots locais e você controla o padrão de operação, Btrfs entra no radar com argumentos muito fortes.

Para workstation Linux de desenvolvimento e laboratório, Btrfs fica mais atraente do que em produção clássica. A possibilidade de snapshot antes de atualização de kernel ou antes de testar mudança grande no ambiente local economiza horas. Para storage de logs, data lake pequeno, artefatos e diretórios com muito crescimento, XFS entrega uma postura mais pragmática.

Se eu precisasse transformar isso em regra de implantação, eu escreveria assim: ext4 para simplicidade e recuperação fácil, XFS para dados grandes e expansão, Btrfs para snapshots e organização avançada do volume. É uma decisão técnica, não religiosa. E, em Linux e DevOps, o filesystem certo é aquele que se encaixa na automação, no tipo de escrita e no plano de recuperação que você realmente vai executar.

Se o seu próximo deploy envolve volume que vai crescer bastante, eu trataria a escolha do filesystem como parte do design do SLO de armazenamento, não como detalhe do instalador. Isso evita refatoração de disco depois que o sistema já está em produção.