XFS vs EXT4 em servidores NVMe: testes de desempenho e comparação prática

Eu comparo XFS EXT4 em servidores NVMe, com base em benchmarks atuais e valores práticos, e mostro em que situações cada sistema de ficheiros apresenta um desempenho significativamente superior. Para tal, concentro-me na taxa de transferência, nas latências e nas cargas de trabalho reais, para que possas tirar o máximo partido do desempenho NVMe no servidor.

Pontos centrais

Para começar, vou resumir brevemente as principais conclusões, antes de abordar os pormenores, os benchmarks e o ajuste.

• E/S aleatória: Ambos muito próximos um do outro; o EXT4 apresenta um débito ligeiramente superior, enquanto o XFS apresenta latências mais uniformes.
• Sequencialmente: O XFS costuma estar na frente no que diz respeito a ficheiros grandes, com o EXT4 logo atrás, apresentando taxas sólidas.
• Metadados: O EXT4 apresenta algumas pequenas vantagens; o XFS tem tempos de resposta constantes.
• Aplicações: Nas bases de dados, os resultados estão muito próximos, com diferenças na casa dos poucos pontos percentuais.
• Afinação: O kernel, o agendador, a profundidade de E/S, o espaço livre e as opções de montagem fazem a diferença.

XFS e EXT4 em NVMe: análise técnica

O EXT4 é considerado um padrão Linux comprovado e oferece, em NVMe, um desempenho muito fiável É a base e serve de referência em muitos comparativos. O XFS está preparado para lidar com ficheiros de grande dimensão, elevado paralelismo e fluxos de dados sequenciais, e consegue tirar muito bem partido da taxa de transferência do NVMe. Em hardware moderno, as diferenças vão diminuindo, uma vez que ambos os sistemas de ficheiros amadureceram ao longo dos anos e as novas versões do kernel continuam a otimizar a pilha NVMe. Nas cargas de trabalho do dia-a-dia, são frequentemente os perfis de carga que fazem a diferença: muitos acessos pequenos e aleatórios ocorrem em intervalos muito curtos, enquanto as grandes transferências sequenciais tendem a favorecer o XFS. Quem toma decisões deve, por isso, conhecer o seu perfil de E/S e não se basear apenas em Classificações olhar.

E/S aleatória em NVMe: blocos pequenos, elevado paralelismo

Em acessos 4K e 8K, ambos os sistemas de ficheiros proporcionam IOPS a um nível muito semelhantes Nível, muitas vezes com uma diferença de apenas alguns pontos percentuais. O EXT4 apresenta, em algumas medições, valores médios ligeiramente superiores na gravação aleatória, o que pode ser visível em cenários semelhantes ao OLTP. O XFS, por outro lado, destaca-se por latências mais uniformes e menos instabilidade ao longo de períodos de execução mais longos, o que favorece tempos de resposta previsíveis em cargas mistas. Em ambientes de produção, as caches, a lógica das aplicações e os percursos de rede ocultam frequentemente estas diferenças subtis. Assim, outros parâmetros de ajuste, como a cache de buffer, a estratégia WAL ou a profundidade de E/S, passam para o primeiro plano (Fonte: 1, 4, 7).

Transferências sequenciais: transferir ficheiros de grande dimensão de forma eficiente

No caso de blocos do tamanho de um MB e de fluxos longos e sequenciais, o XFS costuma sair à frente, porque a disposição dos extensos permite gerir ficheiros grandes de forma eficiente gerido. As janelas de cópia de segurança, as tarefas de arquivamento e os pontos de verificação sequenciais beneficiam visivelmente disso, especialmente em NVMe PCIe 4.0/5.0. O EXT4 mantém-se próximo e oferece taxas muito boas, que dificilmente constituem um limitor em muitas configurações. Quanto mais longo for o fluxo e quanto maior for o ficheiro, mais evidente se torna a vantagem do XFS. O meu breve artigo oferece uma visão geral complementar Comparação de desempenho com cargas de trabalho típicas de servidor (fonte: 4, 5, 9).

Operações com metadados: muitos ficheiros pequenos

As cargas de trabalho com muitas operações de ficheiros sobrecarregam os percursos de metadados e provocam diferenças no bloqueio e no registo em diário Luz. O EXT4 apresenta um ligeiro vantagem em alguns testes quando se trata da criação/eliminação rápida de muitos ficheiros pequenos. Por outro lado, o XFS mantém-se competitivo graças às suas latências constantes, o que o torna uma opção fiável para registos, caches e diretórios de compilação. Em comparação com sistemas de ficheiros alternativos, ambos apresentam uma gestão madura e padrões de reação previsíveis. Quem movimenta grandes quantidades de ficheiros pequenos deve ter em conta as opções de montagem e realizar testes práticos ao longo de períodos de tempo mais prolongados (fonte: 1, 7, 13).

Visão geral dos benchmarks em números

Vou resumir de forma concisa as tendências que se seguem, para que possas identificar rapidamente os padrões típicos reconhecer. E/S aleatória com blocos pequenos: diferenças geralmente mínimas, muitas vezes na ordem de ±3–5 % em IOPS. E/S sequencial com blocos grandes: o XFS costuma estar à frente, especialmente em fluxos longos e ficheiros de grande dimensão. Testes com grande volume de metadados: vantagem parcial do EXT4; o XFS apresenta latências uniformes. Em cenários analíticos, ambos os sistemas de ficheiros utilizam frequentemente cerca de 80–85 % do desempenho teórico do NVMe, dependendo do kernel, do controlador e do firmware do controlador (fonte: 1, 3, 4, 5, 10).

Cenário	Tendência	Vantagem típica	Nota
E/S aleatória (4K/8K)	Muito apertado	O EXT4 apresenta um rendimento ligeiramente superior	O XFS apresenta, frequentemente, latências mais uniformes
Sequencial (≥1 MB)	XFS na frente	Maior velocidade de processamento de ficheiros de grande dimensão	As transmissões longas amplificam o efeito
Operações com metadados	Cabeça a cabeça	O EXT4 é, em alguns casos, mais rápido nas operações de criação/eliminação	O XFS mantém-se estável com carga mista
Bases de dados (OLTP)	Muito apertado	EXT4: TPS ligeiramente superior	O XFS proporciona tempos de resposta mais uniformes
Análise/Relatórios	Inglês	O XFS em análises de grande dimensão	Ambos utilizam 80–85 % do hardware

Testes de desempenho orientados para aplicações: bases de dados e carga mista

Nos testes com o PostgreSQL ou o MySQL, vejo uma disputa renhida, determinada pelos perfis de latência, pelas estratégias WAL e pelas configurações da cache de buffer vive. O EXT4 proporciona, em alguns casos, um pouco mais de transações por segundo em condições de elevado paralelismo. O XFS destaca-se pelos tempos de resposta estáveis, o que pode atenuar as latências de cauda em APIs críticas. As diferenças continuam a ser suficientemente pequenas para que o ajuste da base de dados tenha mais impacto do que a mera mudança de sistema de ficheiros. Quem tiver de tomar esta decisão deve, por isso, medir os testes de duração típicos da carga de trabalho e observar cuidadosamente as métricas da aplicação (fonte: 2, 3, 9).

Versão do kernel, modelos NVMe e a sua influência

Os kernels Linux mais recentes das séries 5.x e 6.x reduzem as latências e aumentam o débito, o que beneficia ambos os sistemas de ficheiros em unidades NVMe rápidas e elimina os pontos de estrangulamento na pilha de E/S reduz. Os SSDs empresariais com grande cache de DRAM e proteção contra perda de energia disfarçam ainda mais as diferenças, porque o controlador e o firmware impõem limites antes que o sistema de ficheiros comece a ter impacto. Os SSDs NVMe de consumo mais económicos revelam essa variação de forma mais evidente, mas, no dia a dia, costumam apresentar desempenhos bastante semelhantes. O PCIe 4.0/5.0 aumenta a margem de manobra, tornando as vantagens sequenciais do XFS mais visíveis. As atualizações do kernel, o firmware NVMe e versões de controladores otimizadas compensam, portanto, de forma mensurável (fonte: 1, 5, 10, 11).

Otimização do NVMe: agendador, profundidade de E/S, espaço livre

Costumo começar com um gestor de tarefas simples, como nenhum ou mq-deadline e ajusto a profundidade de E/S (I/O-Depth) consoante a carga de trabalho, para preencher as filas de forma otimizada. Uma profundidade demasiado elevada gera picos de latência, enquanto uma profundidade demasiado baixa desperdiça recursos paralelos. Reservar 15–20 % de espaço livre reduz a fragmentação e mantém as alocações rápidas. No caso do XFS, analiso a divisão em grupos de alocação, pois estes influenciam significativamente o paralelismo do sistema de ficheiros; um bom tema de introdução são os Grupos de alocação do XFS. Avalio cada alteração através de um teste A/B, para que os efeitos sejam compreensíveis e não passem despercebidas quaisquer deteriorações.

Utilizar as opções de montagem de forma seletiva

As opções de montagem influenciam o registo em diário, os intervalos de confirmação e os percursos de gravação, podendo afetar a latência e o débito percetível ajustar. O EXT4 oferece opções úteis relativas ao modo de registo e aos tempos de confirmação, enquanto o XFS disponibiliza opções para os buffers de registo e os parâmetros de inodes. Adapto estas configurações de acordo com o perfil de carga e documento cada alteração. Quem quiser aprofundar o assunto encontrará dicas concisas sobre parâmetros úteis nos Opções de montagem do EXT4. É importante verificar sempre cada ajuste de montagem com cargas de trabalho reais, e não apenas com testes sintéticos.

Prática de alojamento: seleção em função da carga de trabalho

Para aplicações web clássicas com CMS e lojas online, o EXT4 oferece uma solução fiável Base, porque predominam muitos ficheiros pequenos e padrões mistos de E/S. As bases de dados com elevado paralelismo funcionam muito bem em ambos os sistemas de ficheiros; a minha decisão baseia-se na experiência adquirida, na configuração de monitorização e no conceito de cópia de segurança. Grandes fluxos de dados sequenciais em cópias de segurança e arquivos favorecem o XFS, o que otimiza as janelas de transferência. As cargas de trabalho analíticas também beneficiam da capacidade do XFS de lidar com grandes varreduras, enquanto os perfis mistos muitas vezes apresentam poucas diferenças. Quem estiver em dúvida deve configurar um sistema de teste e efetuar medições com base nas cargas diárias mais importantes.

Estratégia de teste: realista e mensurável

Combino testes de pico curtos com corridas de resistência longas, para poder avaliar tanto os valores máximos como a instabilidade e os efeitos do envelhecimento ver. Em vez de utilizar apenas ferramentas sintéticas, recorro a cópias de bases de dados produtivas, ficheiros de registo típicos e tarefas reais de importação/exportação. A monitorização com o iostat, o perf e as métricas das aplicações está sempre em funcionamento, para que eu possa comprovar as correlações de forma inequívoca. Repito os testes após atualizações do kernel ou alterações de firmware, para detetar regressões numa fase precoce. Desta forma, fica claro se o XFS ou o EXT4 oferecem, no meu ambiente, o melhor equilíbrio entre débito, latência e previsibilidade (fonte: 1).

Registo em diário, barreiras e semântica de sincronização em NVMe

Os detalhes do registo contribuem para determinar os picos de latência e o comportamento de recuperação. O EXT4 utiliza, por predefinição, dados=ordenados e grava metadados no diário, enquanto os dados úteis são guardados antes do commit. Quem precisar de uma velocidade máxima de gravação, assumindo o risco, pode data=writeback ter em conta, o que, no entanto, dificulta a reprodução de gravações após falhas. As versões mais recentes do EXT4 suportam fast_commit, o que agrupa muitas pequenas transações de metadados e reduz os tempos de commit. O XFS mantém o seu próprio registo (jornal), cujo tamanho do registo e logbufs influenciam significativamente o paralelismo e a latência. No NVMe, são Barreiras de gravação Importante: sem a Proteção contra Perda de Energia (PLP), as barreiras devem permanecer ativas para garantir a reordenação do firmware do controlador. Com a PLP, é possível reduzir as barreiras de forma seletiva para acelerar cargas que exigem muitas chamadas fsync() – ponderando sempre o risco envolvido. Para aplicações com requisitos rigorosos de durabilidade (por exemplo, bases de dados), um comportamento correto do fsync() é mais importante do que alguns pontos percentuais a mais de débito.

TRIM/Discard e comportamento a longo prazo do NVMe

Influenciar no Flash Descartar/Aparar- Estratégias que garantem um desempenho de gravação sustentável. O «inline-discard» durante a montagem (discard/async_discard) reduz o trabalho em segundo plano do controlador, mas pode provocar picos de latência sob carga. Periódico fstrim- As execuções (por exemplo, semanais) mantêm o desempenho mais estável em muitos ambientes de produção e separam a libertação de blocos não utilizados do «hot-path». O XFS processa os «discards» de forma eficiente em lotes, enquanto o EXT4 oferece, com descartar=assíncrono uma variante mais suave. É importante que o Discard seja propagado corretamente por todas as camadas (dm-crypt, LVM, MD-RAID, hipervisor). Se forem mantidos, a longo prazo, 15–20 % de reserva, a recolha interna de lixo é reduzida — a variação da latência diminui e o desempenho de escrita permanece mais estável.

RAID, LVM e encriptação: coordenar corretamente as camadas

Antes da formatação, a geometria do bloco deve ser compatível com o RAID/LVM. Para o XFS, a escolha correta de sunit/swidth (Alinhamento de alocação) a eficiência de grandes transferências sequenciais; no EXT4, isto é feito por stride/largura da faixa. Se o alinhamento estiver correto, os ciclos de leitura-modificação-gravação no RAID são minimizados. O LVM-Thin e os instantâneos são práticos, mas aumentam a latência nos caminhos de gravação — o que tem um impacto maior em cargas de trabalho aleatórias do que em varreduras puras. dm-crypt/LUKS consome recursos da CPU e pode limitar as IOPS no caso de blocos pequenos; as tecnologias modernas AES-NI/ARM-Crypto ajudam, mas as latências de cauda tendem normalmente a aumentar ligeiramente. No caso de volumes encriptados, vale a pena reajustar a profundidade de E/S e as afinidades de fila e permitir explicitamente o descarte, caso as diretrizes de segurança o permitam.

CPU/NUMA, afinidade de interrupções e io_uring: ajuste preciso da latência

O NVMe é escalável através de várias filas de envio/conclusão; quem Localização NUMA Tenha em atenção que isto reduz os saltos entre nós. As IRQs NVMe e os threads de trabalho da aplicação devem ser executados no mesmo nó NUMA em que a memória está alocada. No Linux, o «IRQ pinning» e as configurações personalizadas rps/xps-Configurações para manter o caminho dos dados localmente. As cargas de trabalho modernas beneficiam de io_uring (em vez do AIO anterior), que reduz as chamadas de sistema e permite o envio em lote. Nos testes fio, isso traduz-se em latências mais baixas com o mesmo número de IOPS. Profundidades de fila demasiado elevadas (iodepth) distorcem, no entanto, a distribuição da latência; é aconselhável realizar testes escalonados (por exemplo, 1, 4, 16, 64) para identificar o ponto ideal para cada carga de trabalho.

Ambientes de contentores e máquinas virtuais: particularidades na pilha

No que diz respeito aos contentores (overlayfs), o XFS foi durante muito tempo a escolha padrão, porque d_type estava disponível desde cedo de forma fiável e os grandes conjuntos de camadas eram geridos de forma eficiente. Atualmente, as implementações modernas do EXT4 oferecem uma estabilidade equivalente; as diferenças de desempenho são mínimas e devem-se mais ao overlayfs do que ao próprio sistema de ficheiros. Nas máquinas virtuais, predominam as interfaces Virtio/NVMe e os modos de cache do hipervisor: cache=none Além disso, o O_DIRECT no Gast reduz o double-buffering. É importante ter em conta Passagem de descartes e tamanhos de setor uniformes (4K vs. 512e), para evitar a amplificação de gravação. As plataformas baseadas em instantâneos (por exemplo, QCOW2, ZVOL) incorporam a técnica «Copy-on-Write»; a escolha do sistema de ficheiros no sistema convidado continua a ser relevante, mas o backend do anfitrião impõe frequentemente limitações mais cedo do que o próprio XFS/EXT4.

Recuperação, consistência e janelas de manutenção

Ambos os sistemas de ficheiros são considerados robustos, mas o Procedimentos de manutenção diferenciam-se. O EXT4 pode ser verificado exaustivamente com o e2fsck; em volumes muito grandes, este processo demora bastante tempo caso haja erros, mas beneficia de melhorias incrementais (o Fast-Commit reduz a duração da reprodução de transações mais pequenas). O XFS é, em Consistência online configurado; as verificações aprofundadas são executadas com o xfs_repair, que, em caso de emergência, requer muita memória RAM e pode demorar algum tempo quando se trata de árvores de ficheiros muito grandes. Para sistemas em produção, vale a pena fsfreeze antes das instantâneas LVM/de armazenamento, para obter cópias de segurança consistentes com as aplicações; além disso, as bases de dados devem acionar os seus próprios mecanismos de checkpoint/cópia de segurança. Quem tiver SLAs com RTO/RPO curtos deve planear explicitamente testes de recuperação – isso desmistifica os mitos e revela janelas de inatividade realistas.

Aspectos relacionados com funcionalidades para além do desempenho bruto

O desempenho não é tudo. O XFS oferece ReflinkCópias baseadas em [ext4] e hooks de deduplicação, o que poupa espaço de armazenamento em imagens de máquinas virtuais e grandes acervos multimédia e reduz os tempos de cópia. O EXT4 destaca-se pelo amplo suporte a ferramentas e por predefinições conservadoras, que simplificam as implementações. Quotas estão disponíveis em ambos os mundos; o XFS destaca-se por Cotas de projeto para quotas baseadas em diretórios em grandes estruturas multitenant. Opções como noatime/relatime/lazytime reduzem sensivelmente a carga de gravação de metadados. Quem utilizar a encriptação por diretório ou por ficheiro (fscrypt) deve ter em conta a ligeira sobrecarga em caso de pequenos acessos aleatórios e reservar recursos da CPU.

Evitar erros de medição: armadilhas típicas

Muitas das supostas diferenças entre FS são, na verdade, Artefactos de teste. Os conjuntos de dados demasiado pequenos acabam no cache de página e ocultam as diferenças; os conjuntos de dados devem ser maiores do que a RAM disponível. A ausência de um aquecimento distorcem o perfil de gravação aleatória na memória Flash; da mesma forma, as tarefas de manutenção executadas em paralelo (scrubs, rebuilds, fstrim) provocam valores atípicos. Nos testes fio, é necessário esclarecer se direct=1 é utilizado para verificar se as fases do fsync() estão definidas de forma realista e se as combinações de leitura/gravação decorrem de forma intercalada ou em fases. Para obter resultados reproduzíveis, são necessárias frequências fixas da CPU (sem reguladores de escalabilidade agressivos), uma carga de fundo constante e um isolamento claro entre o teste e a monitorização.

Lista de verificação prática: eis como deves proceder

• Esclarecer o perfil da carga de trabalho: tamanhos de bloco, rácio de leitura/gravação, orçamento de latência, comportamento em picos de tráfego.
• Limpar a pilha: Verificar o kernel, o firmware NVMe, as versões dos controladores; a afinidade de IRQ e o NUMA.
• Alinhar o layout: Definir corretamente o alinhamento RAID/LVM (sunit/swidth ou stride/stripe-width).
• Testar as opções de montagem: Barreiras, intervalos de commit, noatime/relatime/lazytime; parâmetros de registo do XFS.
• Calibrar a profundidade de E/S: Ponderar entre latência e débito, encontrar o ponto ideal para cada aplicação.
• Prever espaço livre: 15–20 % Reserva para latências uniformes e menor fragmentação.
• Definir a estratégia de descarte: fstrim em linha vs. fstrim periódico, propagar por todas as camadas.
• Cópias de segurança e recuperação: Testar os processos fsfreeze/Snapshot, verificar o tempo de inatividade de forma realista.
• Medições A/B: Alterar apenas uma variável e correlacionar os resultados com as métricas da aplicação.

Resumo: Orientação para a tomada de decisões sem mitos

O XFS e o EXT4 oferecem um desempenho muito elevado em NVMe, sendo que as diferenças, na maioria das vezes, permanecem moderado e dependem fortemente do perfil de E/S. As cargas aleatórias com blocos pequenos apresentam resultados muito próximos, enquanto os fluxos sequenciais longos tendem a favorecer o XFS. O EXT4 destaca-se com uma taxa de transferência ligeiramente superior em alguns padrões transacionais, enquanto o XFS apresenta latências constantes em testes de duração. A versão do kernel, os modelos NVMe, o agendador, a profundidade de E/S, o espaço livre e as opções de montagem influenciam frequentemente o resultado de forma mais significativa do que a mera escolha do sistema de ficheiros. Quem efetua medições claras e compreende as suas próprias cargas de trabalho toma uma decisão fundamentada — sem lendas e com resultados mensuráveis Lucro.