A tirania do recordsize: como salvar seus SSDs da amplificação de escrita no ZFS

Você investiu pesado em um array de armazenamento all-flash. Comprou SSDs NVMe Enterprise com alta durabilidade (DWPD), configurou sua rede de 100GbE e instalou o ZFS esperando performance estelar. No entanto, ao migrar seu banco de dados PostgreSQL ou suas máquinas virtuais, algo estranho acontece. A latência de escrita é inconsistente, o throughput está abaixo do esperado e, pior, seus discos estão se desgastando a uma velocidade alarmante. O culpado raramente é o hardware. O assassino silencioso da sua infraestrutura é uma configuração de uma única linha que a maioria dos administradores ignora: o recordsize.

O ZFS é um sistema de arquivos transacional baseado em Copy-on-Write (CoW). Isso significa que ele nunca sobrescreve dados no local (in-place). Sempre que um bloco é modificado, o ZFS aloca um novo bloco, escreve os dados modificados e atualiza os ponteiros da árvore Merkle até o Uberblock. Essa arquitetura garante uma integridade de dados inigualável, mas introduz uma mecânica perigosa se a geometria dos seus dados não estiver alinhada com a geometria do sistema de arquivos.

Resumo em 30 segundos

O Padrão é Perigoso: O recordsize padrão do ZFS é 128k, o que é ótimo para arquivos grandes (vídeos), mas desastroso para bancos de dados e VMs que fazem escritas pequenas e aleatórias (4k, 8k, 16k).

Amplificação de Escrita: Escrever 4k em um registro de 128k força o ZFS a ler os 128k originais, modificar os 4k na memória e gravar novos 128k no disco. Isso aumenta o desgaste do SSD em até 32 vezes.

Alinhamento é Tudo: Configurar o recordsize para corresponder exatamente ao tamanho da página da sua aplicação (ex: 16k para InnoDB) elimina o ciclo de leitura-modificação-escrita e triplica o desempenho.

A anatomia do desastre: entendendo o padrão de 128k

Quando Jeff Bonwick e a equipe da Sun Microsystems projetaram o ZFS, os discos rígidos mecânicos dominavam a terra. O objetivo era maximizar o throughput sequencial para mitigar o tempo de busca (seek time) das cabeças de leitura. O valor padrão de recordsize=128k foi escolhido como um meio-termo sensato. Ele permite que o ZFS trate arquivos como uma série de blocos de 128k, o que é excelente para streaming, backups e servidores de arquivos gerais.

O problema surge quando aplicamos essa lógica de 2005 aos workloads modernos de 2025 rodando em memória flash. Bancos de dados relacionais (OLTP) e discos virtuais de hypervisors não escrevem em fluxos contínuos. Eles operam como metralhadoras de I/O aleatório, disparando pequenas atualizações de 4k, 8k ou 16k em locais dispersos do armazenamento.

Se você tem um dataset configurado com o padrão de 128k e seu banco de dados solicita a gravação de apenas 8k de dados, o ZFS não pode simplesmente alterar esses 8k no disco. Lembre-se: CoW proíbe sobrescrita. O ZFS é obrigado a tratar o bloco de 128k como a menor unidade atômica de gerenciamento para aquele arquivo.

Figura: O ciclo destrutivo do Read-Modify-Write: uma pequena escrita de 8k força a movimentação de 128k de dados.

A mecânica brutal do read-modify-write

O fenômeno descrito acima é conhecido como Read-Modify-Write (RMW). É aqui que a performance morre e a latência de cauda (tail latency) dispara. Vamos dissecar o que acontece nos bastidores de uma transação de escrita desalinhada:

Solicitação: A aplicação envia uma escrita de 4k.
Leitura Forçada: O ZFS identifica que esses 4k pertencem a um registro lógico de 128k. Como ele precisa calcular o checksum de todo o registro para garantir a integridade, ele primeiro precisa ler os 128k atuais do disco para a memória (ARC).
Modificação: Na memória, o ZFS altera os 4k dentro do buffer de 128k.
Cálculo de Checksum: O novo checksum do bloco de 128k é calculado.
Escrita: O ZFS aloca espaço livre e grava os 128k inteiros no disco.

O resultado matemático é assustador. Para persistir 4k de dados úteis, seu sistema processou 128k de leitura e 128k de escrita. Isso é uma amplificação de I/O massiva. Se o seu SSD suporta 100.000 IOPS de escrita, você efetivamente reduziu essa capacidade drasticamente, pois cada operação lógica consome muito mais largura de banda do backend do que o necessário.

⚠️ Perigo: Em SSDs de consumo ou de entrada (Read Intensive), essa amplificação destrói a vida útil (TBW) do drive em meses, não anos. Você está queimando células NAND para gravar dados que não mudaram (os 124k restantes do bloco).

O RAIDZ se torna uma armadilha para IOPS aleatórios

Se o RMW em um único disco já é ruim, em uma configuração RAIDZ (o equivalente do ZFS ao RAID 5 ou 6) a situação se torna catastrófica para cargas aleatórias. O RAIDZ foi projetado para maximizar a capacidade de armazenamento, não a performance de IOPS aleatórios.

Em um vdev RAIDZ, o tamanho do bloco lógico (recordsize) é dividido entre os discos de dados, e a paridade é calculada. No entanto, existe um conceito crítico chamado ashift (alinhamento de setor) e alocação mínima. Cada setor físico do disco (geralmente 4k em SSDs modernos) é a unidade mínima de escrita.

Quando você força escritas pequenas (sub-bloco) em um RAIDZ com recordsize grande, você sofre duplamente:

Overhead de Paridade: Para cada bloco modificado, a paridade precisa ser recalculada e reescrita.
Padding (Preenchimento): O ZFS precisa arredondar as alocações para múltiplos de (p+1) setores para evitar buracos na geometria do RAIDZ. Isso resulta em espaço desperdiçado e mais dados inúteis sendo gravados.

Para cargas de trabalho de banco de dados ou virtualização em Flash, a regra de ouro é clara: Use Espelhamento (Mirrors). Um pool de mirrors (RAID 10 equivalente) escala a performance de leitura e escrita linearmente com o número de vdevs e elimina a complexidade do cálculo de paridade e padding do RAIDZ durante o RMW.

Tabela Comparativa: Impacto da Topologia em Cargas Aleatórias

Característica	RAIDZ (Z1/Z2)	Mirror (Espelhamento)
Eficiência de Espaço	Alta (67% a 90% útil)	Baixa (50% útil)
IOPS de Escrita Aleatória	Limitado à velocidade de 1 disco por vdev	Soma da velocidade de todos os vdevs
Amplificação de Escrita	Altíssima (Padding + Paridade + RMW)	Baixa (Apenas RMW se desalinhado)
Resilvering (Reconstrução)	Lento e intensivo em CPU	Rápido e linear
Cenário Ideal	Backup, Arquivos de Mídia, WORM	Bancos de Dados, VMs, Containers

Sincronizando o recordsize com a página de dados

A solução para a tirania do recordsize não é mágica, é engenharia. Precisamos alinhar a geometria do sistema de arquivos com a geometria da aplicação. Quando o recordsize do ZFS é igual ao tamanho da escrita da aplicação, o ciclo RMW desaparece.

Se o Postgres escreve uma página de 8k e o ZFS tem um recordsize=8k:

O ZFS recebe 8k.
O ZFS aloca um novo bloco de 8k.
O ZFS grava 8k.
Fim.

Não há leitura prévia. Não há modificação em memória de dados adjacentes. O ZFS trata aquela escrita como um registro completo. Isso transforma uma operação pesada em uma operação atômica pura.

Figura: O Nirvana do Alinhamento: Quando o tamanho do registro casa com a página da aplicação, a eficiência é total.

Guia de Alinhamento por Aplicação

Aqui estão os valores recomendados para as cargas de trabalho mais comuns em infraestrutura enterprise:

PostgreSQL: O padrão de página é 8k.
- Comando: zfs set recordsize=8k pool/dataset/postgres
MySQL / MariaDB (InnoDB): O padrão de página é 16k.
- Comando: zfs set recordsize=16k pool/dataset/mysql
Máquinas Virtuais (KVM/QEMU em qcow2): O cluster padrão de muitos sistemas de arquivos guest (NTFS, EXT4) é 4k. No entanto, o qcow2 tem seus próprios clusters.
- Estratégia: Para arquivos de imagem de disco (vmdk, qcow2) em datasets, 64k costuma ser um "ponto ideal" (sweet spot) entre fragmentação de metadados e amplificação.
ZVols (Block Device): Aqui usamos volblocksize em vez de recordsize.
- Para iSCSI/Fibre Channel servindo VMFS ou NTFS: 32k ou 64k geralmente oferecem o melhor equilíbrio.

💡 Dica Pro: A compressão LZ4 do ZFS é sua aliada. Mesmo com recordsize pequeno (ex: 8k), o LZ4 pode comprimir esse bloco para 2k ou 3k físicos. O ZFS em SSDs modernos lida com alocação de tamanho variável de forma exímia. Não tenha medo de combinar recordsize ajustado com compression=lz4 (ou zstd).

Verificando a redução de I/O no backend

Como saber se suas alterações surtiram efeito? O ZFS fornece ferramentas de telemetria transparentes. Não confie na sua intuição, confie nos números.

Antes de ajustar, execute uma carga de trabalho e observe o zpool iostat. Preste atenção nas colunas de largura de banda (bandwidth). Se sua aplicação diz que está escrevendo 10MB/s, mas o zpool iostat mostra 100MB/s de escrita física nos discos, você tem um Fator de Amplificação de Escrita (WAF) de 10x.

Após ajustar o recordsize (lembrando que a mudança só afeta novos dados escritos), monitore novamente.

zpool iostat -r 5

Você deve observar uma convergência entre a taxa de escrita lógica (o que a app pede) e a física (o que vai para o disco). Além disso, o uso de CPU (sys time) deve cair, pois o sistema gasta menos tempo calculando checksums de dados que não foram modificados e copiando memória desnecessariamente.

Figura: O colapso da amplificação: Gráfico demonstrando a queda drástica na escrita física após o ajuste do recordsize.

Outra métrica vital está no arc_summary. Procure pela seção "DMU" (Data Management Unit). Um alto número de operações de "object rewrite" ou RMW excessivo pode ser diagnosticado aqui.

O imperativo da geometria de dados

A era do armazenamento definido por software exige que deixemos de tratar o disco como uma caixa preta passiva. O ZFS é um sistema de arquivos incrivelmente robusto, mas ele obedece às leis da física e da lógica. Ignorar o recordsize em arrays all-flash não é apenas uma ineficiência; é negligência financeira e técnica.

Ao alinhar suas escritas, você não apenas ganha performance "de graça". Você estende a vida útil dos seus SSDs, reduz a latência para seus usuários finais e diminui a carga na sua CPU. Antes de colocar qualquer banco de dados em produção sobre ZFS, faça a pergunta: "Qual é o tamanho da minha página?". A resposta a essa pergunta vale mais do que o upgrade de hardware que você estava planejando comprar.

Referências & Leitura Complementar

OpenZFS Documentation: Workload Tuning - Database workloads.
PostgreSQL Documentation: Chapter 73. Physical Storage & Page Layout.
NVM Express Base Specification: Write Amplification & Endurance Management.
FreeBSD Mastery: ZFS por Michael W. Lucas e Allan Jude (Referência canônica para administradores).

Perguntas Frequentes (FAQ)

Qual é o recordsize padrão do ZFS e por que ele é problemático para bancos de dados?

O padrão é 128k. Para bancos de dados que escrevem páginas de 8k ou 16k, isso força o ZFS a ler, modificar e regravar 128k inteiros para uma pequena alteração, gerando enorme amplificação de escrita e latência.

Devo usar RAIDZ1 ou RAIDZ2 em SSDs para performance?

Geralmente não para cargas aleatórias. O RAIDZ limita os IOPS à velocidade de um único disco por vdev e agrava a amplificação de escrita devido ao padding. Espelhamento (Mirrors) é superior para IOPS e integridade em Flash.

A compressão LZ4 ajuda a mitigar o problema do recordsize?

A compressão ajuda a economizar espaço e largura de banda, mas não resolve o problema fundamental do ciclo Read-Modify-Write se o recordsize for muito maior que a escrita da aplicação. O alinhamento geométrico deve vir primeiro.