A matemática oculta da expansão de RAIDZ no OpenZFS: custos de rebalanceamento e fragmentação

A expansão de RAIDZ é, sem dúvida, o recurso mais aguardado da última década no ecossistema OpenZFS. Durante anos, a resposta padrão nos fóruns de storage para "posso adicionar um disco ao meu RAIDZ?" foi um sonoro e doloroso "não". A arquitetura baseada na Árvore de Merkle e a imutabilidade dos ponteiros tornavam essa operação matematicamente proibitiva sem uma reescrita completa dos dados.

Com o advento do OpenZFS 2.2 (e versões posteriores integradas em sistemas como TrueNAS SCALE), essa barreira foi quebrada. No entanto, a física não perdoa. A implementação dessa funcionalidade não é mágica; é um compromisso de engenharia fascinante que troca ciclos de CPU e I/O por flexibilidade. Se você acredita que adicionar um disco a um vdev RAIDZ2 vai magicamente redistribuir seus dados e recuperar eficiência de paridade instantaneamente, precisamos conversar sobre como os metadados do ZFS realmente funcionam.

Resumo em 30 segundos

Não é Rebalanceamento Automático: A expansão libera espaço bruto, mas os dados antigos mantêm a proporção de paridade antiga (ineficiente). Apenas novos dados aproveitam a nova geometria.

O Custo do "Reflow": O ZFS move os dados existentes para liberar segmentos no novo disco, mas não altera o tamanho lógico dos blocos nem seus checksums, evitando a complexidade do Block Pointer Rewrite.

Fragmentação Inevitável: O processo pode introduzir fragmentação nos espaços livres, exigindo estratégias de reescrita (como zfs send/recv) para desfragmentar e recuperar a eficiência de armazenamento.

O mito do Block Pointer Rewrite (BPR)

Para entender a expansão, você precisa entender por que ela demorou tanto. No ZFS, o endereço de um bloco é parte do checksum do seu bloco pai. Se você mover um bloco de dados e mudar seu endereço ou sua estrutura lógica, o checksum muda. Isso altera o bloco pai, que altera o avô, propagando-se até o uberblock.

Para fazer um "restripe" tradicional (como em RAID5 de hardware), teríamos que reescrever todos os ponteiros do sistema de arquivos. Isso é o lendário Block Pointer Rewrite (BPR), um recurso que nunca foi implementado devido à sua complexidade e risco de corrupção.

A expansão atual do RAIDZ não é BPR. Ela é uma técnica engenhosa que mantém os ponteiros lógicos intactos, mas altera o mapeamento físico dos dados subjacentes.

Figura: A abstração da expansão: O ponteiro lógico (acima) permanece inalterado, enquanto o mapeamento físico (abaixo) redistribui os dados para incluir o novo dispositivo.

Anatomia do Reflow: Movendo sem tocar

Quando você executa zpool attach, o ZFS inicia um processo de "reflow". Imagine que você tem um RAIDZ1 de 3 discos (2 dados + 1 paridade). Você adiciona um quarto disco.

O sistema percorre o mapa de alocação (metaslabs) e começa a mover os dados existentes. O objetivo não é mudar a geometria dos dados antigos, mas sim redistribuí-los fisicamente para que o espaço livre seja equalizado entre todos os 4 discos.

💡 Dica Pro: O processo de expansão acontece em segundo plano, mas compete por IOPS. Em pools de HDDs mecânicos (spinners), espere uma degradação significativa de performance durante a operação. Use zpool status para monitorar o progresso.

O segredo aqui é que os dados antigos, que foram gravados com uma largura de stripe de 3 discos, continuam sendo lidos e interpretados como stripes de 3 discos, mesmo estando espalhados por 4 discos. O ZFS lê os metadados, descobre que aquele bloco foi escrito na "Era dos 3 Discos" e aplica a matemática de reconstrução apropriada para aquela geometria.

A realidade híbrida e a eficiência perdida

Aqui reside a "matemática oculta" que pega muitos administradores de surpresa. A eficiência de espaço (ratio de paridade) é definida no momento da escrita.

Cenário Prático:

Você tem um RAIDZ2 com 6 discos (4 dados + 2 paridade). Eficiência de armazenamento: 66%.
Você expande para 10 discos. A nova geometria ideal seria (8 dados + 2 paridade). Eficiência de armazenamento: 80%.
O Problema: Os Terabytes de dados que já existiam no pool continuam com a eficiência de 66%. Eles ocupam o mesmo espaço bruto de antes, apenas espalhados por mais discos.

O ganho de espaço imediato que você vê após a expansão vem apenas do disco novo adicionado, mas você não recupera o "overhead" de paridade dos dados antigos. O pool torna-se um híbrido de geometrias: blocos antigos com ratio ruim e blocos novos com ratio bom.

Figura: Geometria Híbrida: Dados antigos (azul claro) mantêm a proporção de paridade original, desperdiçando espaço potencial, enquanto novos dados (azul escuro) aproveitam a largura total do novo array.

O custo oculto da fragmentação

A expansão do RAIDZ funciona copiando dados alocados para novas posições para liberar segmentos contíguos no novo disco. No entanto, diferentemente de uma cópia sequencial limpa, o reflow pode deixar "buracos" no espaço endereçável, dependendo de como os dados estavam dispostos anteriormente.

Embora o ZFS tenha alocadores excelentes (como o Gang Block em casos extremos), a expansão tende a aumentar a fragmentação do espaço livre. Isso significa que futuras escritas podem ter dificuldade em encontrar grandes faixas contínuas de espaço, forçando o drive a buscar (seek) mais, o que é mortal para HDDs.

⚠️ Perigo: Se o seu pool estiver muito cheio (>90%) antes da expansão, o processo será excruciantemente lento e resultará em fragmentação severa. Nunca espere o pool lotar para expandir.

Recuperando a eficiência: A reescrita manual

Se você deseja que seus dados antigos aproveitem a nova eficiência de paridade (e liberem espaço real), você deve reescrevê-los. Não existe um comando zpool rebalance mágico.

A única maneira de transformar dados "antigos" em dados "novos" é forçá-los a passar pelo pipeline de escrita do ZFS novamente.

Métodos de Reescrita:

ZFS Send/Recv (Recomendado): Envie o dataset para um novo dataset no mesmo pool (ou outro), destrua o original e renomeie o novo. Isso garante blocos sequenciais e nova geometria.
CP/MV: Copiar arquivos individualmente. Menos eficiente, perde snapshots, mas funciona para arquivos soltos.

Tabela Comparativa: Métodos de Crescimento

Para situar onde a expansão se encaixa no seu arsenal de administração de storage, compare as opções:

Característica	Expansão de RAIDZ (Novo)	Adicionar Novo VDEV (Clássico)	Substituir Discos (Autoexpand)
Custo Inicial	Baixo (1 disco por vez)	Alto (Mínimo 3+ discos para RAIDZ)	Médio/Alto (Todos os discos do VDEV)
Eficiência de Espaço	Híbrida (Melhora apenas em novos dados)	Mantém a eficiência do novo VDEV	Melhora total após resilver de todos
IOPS	Mantém IOPS do VDEV único (aprox.)	Dobra IOPS (Striping entre VDEVs)	Mantém IOPS
Risco	Estresse de rebalanceamento nos discos	Baixo (apenas adiciona)	Alto (stress de resilver repetido)
Complexidade	Média (Requer reescrita para otimizar)	Baixa	Baixa (mas demorada)

Figura: Fluxo de Decisão: Escolhendo o caminho correto para expansão de storage baseada em orçamento, necessidade de IOPS e eficiência.

O Veredito do Engenheiro

A expansão de RAIDZ é uma ferramenta de conveniência, não de performance. Ela foi projetada para o cenário SOHO (Small Office/Home Office) e entusiastas que não podem comprar 8 discos de 20TB de uma só vez.

Para ambientes Enterprise onde IOPS e latência são críticos, adicionar novos VDEVs continua sendo a arquitetura superior. O custo de computação do reflow e a geometria mista podem introduzir variabilidade de latência indesejada em cargas de trabalho transacionais.

Use a expansão se o orçamento for o gargalo. Use novos VDEVs se a performance for o objetivo. E lembre-se: RAID não é backup, e expansão de RAID é uma cirurgia de coração aberto nos seus dados. Tenha backups testados antes de digitar zpool attach.

Referências & Leitura Complementar

OpenZFS Pull Request #12225: "RAIDZ Expansion" - A documentação técnica original da implementação por Matt Ahrens.
Foundation of the ZFS Expansion: Palestra de Matt Ahrens no OpenZFS Developer Summit (2021/2023) detalhando a matemática do reflow.
FreeBSD Man Pages (zpool-attach): Documentação oficial sobre as limitações e sintaxe do comando de expansão.

Perguntas Frequentes (FAQ)

A expansão do RAIDZ rebalanceia os dados existentes automaticamente?

Não. O OpenZFS utiliza uma técnica de 'reflow' que move os dados fisicamente para liberar espaço e distribuir a carga, mas mantém a proporção de paridade original (ex: um arquivo gravado em um RAIDZ1 de 3 discos continua com a eficiência de 3 discos, mesmo que agora existam 4). Apenas novos dados gravados aproveitarão a nova geometria e eficiência de paridade.

O processo de expansão é seguro contra falhas de energia?

Sim. O ZFS é um sistema de arquivos transacional (Copy-on-Write). O processo de expansão possui checkpoints robustos gravados no disco. Se o sistema reiniciar ou perder energia durante a expansão, ele retoma de onde parou assim que o pool for importado novamente, garantindo a integridade das estruturas de dados e da Árvore de Merkle.

Como recupero a eficiência de espaço nos dados antigos?

Você deve reescrever os dados. O método mais eficaz é utilizar `zfs send` para enviar o dataset para um novo local (mesmo que temporário) e depois trazê-lo de volta (`zfs recv`), ou simplesmente copiar os arquivos. Ao serem reescritos, os dados passarão pelo alocador novamente e adotarão a nova largura de stripe e eficiência de paridade do pool expandido.