A Ilusão da Expansão RAIDZ: O Custo Oculto da Paridade Estática

Depois de uma década de choro coletivo nas issues do GitHub e promessas de "está quase pronto" que duraram mais que a maioria dos casamentos modernos, a expansão de RAIDZ finalmente aterrissou no OpenZFS (versão 2.3+). A multidão de entusiastas do TrueNAS e administradores de home labs soltou fogos. Finalmente, o sonho de adicionar um único disco ao seu array Z2, tal qual um usuário de Synology ou Unraid, tornou-se realidade.

Mas, como qualquer sysadmin que já viu um servidor pegar fogo sabe: se parece bom demais para ser verdade, é porque você não leu a documentação técnica. A expansão de RAIDZ não é mágica. É matemática. E a matemática, meus caros, é cruel com quem espera almoço grátis.

Resumo em 30 segundos

Não é um Rebalanceamento: Adicionar um disco ao RAIDZ não redistribui os dados existentes para aproveitar a nova largura de banda ou eficiência de paridade.

A "Geometria Fantasma": Seus dados antigos permanecem gravados com a proporção de paridade antiga (ineficiente) até serem reescritos.

Custo de IOPS: O processo de expansão (reflow) consome recursos significativos e, sem uma reescrita forçada posterior, você terá um pool com performance mista e imprevisível.

A expectativa frustrada de capacidade imediata

O cenário é clássico. Você tem um vdev RAIDZ1 com 3 discos de 10TB. Você está ficando sem espaço. Você compra o quarto disco, espeta no chassi, roda o comando mágico (ou clica no botão da GUI do TrueNAS Scale) e espera ver sua capacidade útil saltar e sua eficiência de paridade melhorar instantaneamente.

Você espera que o ZFS pegue todos os seus blocos de dados, que hoje ocupam 2 discos + 1 de paridade (2d+1p), e os transforme magicamente em 3 discos + 1 de paridade (3d+1p), liberando aquele suculento espaço desperdiçado.

Spoiler: Isso não acontece.

O ZFS é um sistema de arquivos Copy-on-Write (CoW). Ele odeia, com todas as forças do seu código fonte, modificar dados que já foram escritos. Quando você expande um RAIDZ, o ZFS realiza um processo chamado "reflow". Ele percorre os metadados e diz: "Ei, agora temos mais espaço físico endereçável aqui". Mas ele não toca nos dados antigos.

Como a expansão preserva a geometria antiga

Aqui reside o "custo oculto". A eficiência do RAIDZ é baseada na largura da faixa (stripe width).

Antes da expansão: Em um RAIDZ1 de 3 discos, cada stripe tem 2 blocos de dados e 1 de paridade. Eficiência de armazenamento: 66%.
Depois da expansão: O novo layout permite 3 blocos de dados e 1 de paridade. Eficiência de armazenamento: 75%.

O problema é que os Terabytes de ISOs de Linux (eu sei que são filmes, não minta) que você gravou antes da expansão continuam sentados lá com a geometria antiga de 66%. O novo disco adicionado fica, essencialmente, com grandes vazios nas áreas correspondentes aos dados antigos.

💡 Dica Pro: O espaço extra que você "ganhou" só será utilizado efetivamente por novos dados gravados após a expansão. Os dados velhos continuam ocupando o mesmo espaço físico de antes, desperdiçando a eficiência potencial do novo disco.

Figura: Visualização da Alocação de Blocos: Note como os dados antigos (Azul) ignoram o novo disco, mantendo a ineficiência original.

O erro de confiar apenas na atualização dos metadados

Muitos administradores juniores olham para o comando zpool list após a expansão, veem o espaço livre total aumentar e acham que o trabalho acabou. Isso é uma armadilha.

O processo de expansão do OpenZFS faz um reflow do mapa de alocação de espaço (space map). Ele basicamente diz ao sistema: "Olha, agora podemos alocar blocos neste novo intervalo lógico". No entanto, a paridade é estática no momento da escrita.

Se você não forçar uma reescrita, seu pool se torna um Frankenstein de geometrias.

Leitura de dados antigos: Lê de 3 discos (o quarto disco fica ocioso).
Leitura de dados novos: Lê de 4 discos.

Isso cria uma inconsistência de performance brutal. Em um ambiente de produção ou homelab sério, ter latência variável dependendo da "idade" do arquivo é um pesadelo para diagnóstico de performance. O disco novo terá muito menos carga de leitura que os veteranos, criando um desbalanceamento de desgaste e calor.

A estratégia de reescrita forçada para diluição da paridade

Se você quer realmente ganhar o espaço e a performance que o marketing prometeu, você precisa trabalhar por isso. Não existe um botão "Defrag/Rebalance" no ZFS como existe no Btrfs.

Para converter os dados antigos (2d+1p) para a nova geometria (3d+1p), eles precisam ser lidos e gravados novamente. O ZFS, ao receber a nova gravação, usará a nova largura do vdev.

Métodos de Reescrita (Do Pior para o Melhor):

O Método "Script Kiddie" (cp e mv): Copiar os arquivos para uma pasta temporária e mover de volta.
- Problema: Fragmentação massiva. Você vai quebrar a contiguidade dos seus dados, transformando seu array sequencial em uma máquina de IOPS aleatório. Não faça isso.
O Método "ZFS Send/Recv Local": Criar um novo dataset, enviar o snapshot do antigo para o novo, destruir o antigo, renomear o novo.
- Vantagem: Preserva a estrutura de blocos melhor que o cp.
- Desvantagem: Requer espaço livre suficiente no pool para duplicar o dataset durante a operação. Se você expandiu porque estava com 99% de uso, isso é impossível.
O Método "Rebalanceamento In-Place" (Ferramentas de Terceiros): Existem scripts (como o zfs-rebalance) que leem e reescrevem arquivos.

⚠️ Perigo: Scripts que apenas fazem touch nos arquivos não funcionam, pois o ZFS detecta que o conteúdo não mudou. É necessário reescrever o conteúdo real.

Tabela Comparativa: Expansão vs. Métodos Tradicionais

Para quem ainda acha que a expansão de RAIDZ é a bala de prata, vamos aos números frios comparando com as abordagens clássicas de gerenciamento de storage.

Característica	Expansão de RAIDZ (Novo Recurso)	Adicionar Novo VDEV (Striping)	Backup / Destruir / Restaurar
Disponibilidade	Online (Pool acessível)	Online (Pool acessível)	Offline (Downtime total)
Ganho de Espaço	Imediato (mas ineficiente para dados velhos)	Imediato (100% eficiente)	Imediato (100% eficiente)
Custo de Paridade	Misto (Velho=Alto, Novo=Baixo)	Mantém o custo do novo VDEV	Otimizado para a nova geometria
Performance	Degrada durante o reflow	Aumenta (mais vdevs = mais IOPS)	Máxima (dados sequenciais)
Risco	Médio (Stress nos discos existentes)	Baixo	Alto (Se o backup falhar...)
Reversibilidade	Nenhuma (Caminho sem volta)	Nenhuma	Total (pode recriar como quiser)

Métricas que confirmam a realidade

Se você monitorar seu pool com zpool iostat -v durante uma leitura sequencial de um arquivo antigo após a expansão, verá algo curioso. Digamos que você expandiu de 3 para 4 discos.

Ao ler o "Arquivo_Antigo.mkv":

Disco 1: 150 MB/s
Disco 2: 150 MB/s
Disco 3: 150 MB/s
Disco 4 (Novo): 0 KB/s (ou próximo disso)

Isso prova que a largura de banda de leitura para dados antigos não aumentou. Você adicionou hardware, aumentou o consumo de energia, aumentou o ruído, mas sua velocidade de leitura para o acervo histórico permanece presa no passado. Apenas novos arquivos aproveitarão a soma das velocidades dos 4 discos.

O Veredito do Sysadmin

A expansão de RAIDZ é uma ferramenta de conveniência para o usuário doméstico ou para o administrador de SMB que não tem orçamento para comprar um chassi novo ou um conjunto completo de discos para um novo vdev. É um "band-aid" técnico impressionante, desenvolvido por mentes brilhantes da Fundação OpenZFS, mas não deixa de ser um compromisso.

Se você gerencia storage enterprise onde SLA e performance preditiva são reis, a regra de ouro permanece: planeje sua capacidade corretamente desde o dia zero. Se precisar crescer, adicione novos VDEVs ou substitua os discos por maiores (autoexpand). A expansão de largura de RAIDZ deve ser seu último recurso, não sua estratégia padrão de crescimento.

Use-a sabendo que, para "consertar" a bagunça da paridade mista, você terá que gastar ciclos de CPU e IOPS reescrevendo seus dados mais tarde. E como sabemos, em TI, "mais tarde" muitas vezes significa "quando o disco falhar e o resilver demorar 3 semanas".

Referências & Leitura Complementar

OpenZFS GitHub Pull Request #8853: "RAIDZ Expansion" - A implementação técnica real e as discussões sobre as limitações de reescrita de paridade.
Matthew Ahrens (Delphix) Talks: Apresentações no OpenZFS Developer Summit detalhando a alocação de espaço e o conceito de "Reflow".
FreeBSD Man Pages (zpool-attach): Documentação oficial sobre as restrições de expansão de vdevs raidz.

FAQ: Perguntas que você deveria ter feito antes de rodar o comando

O comando zpool attach rebalanceia meus dados automaticamente?

Não. O OpenZFS apenas realiza um 'reflow' para liberar espaço contíguo e atualizar os mapas de alocação. Os blocos de dados antigos mantêm a proporção de paridade original (ineficiente) e a largura de stripe antiga até que sejam explicitamente reescritos pelo administrador.

É seguro expandir um RAIDZ durante operações de escrita intensa?

Tecnicamente sim, pois o processo é online e desenhado para concorrência. Porém, na prática, a performance de IOPS sofrerá uma degradação severa durante o reflow, pois o sistema compete pelos mesmos discos. Recomenda-se fortemente fazer isso em janelas de manutenção ou baixo tráfego.

Posso remover o disco adicionado se eu mudar de ideia?

Não. A expansão de RAIDZ é uma operação unidirecional. Uma vez que o vdev foi expandido e os metadados atualizados, não há 'undo' ou comando de remoção para vdevs de topo RAIDZ sem destruir o pool inteiro e restaurar do backup.