Além do TAKT

zfs

Um fork do OpenZFS. O branch padrão espelha o master upstream; o trabalho próprio do projeto fica em branches separados: um protótipo de reconfiguração in loco do RAIDZ e o material para propô-lo upstream.

OpenZFS
RAIDZ
C

Repositório no GitHub RFC: reconfiguração in loco do RAIDZ Projeto relacionado: escrow-box

Status: Um protótipo validado, não um recurso pronto, nas palavras do próprio repositório: não está pronto para produção e o formato em disco não é definitivo. Testado com matrizes de perda de dispositivos, pontos de interrupção por crash, KASAN e execuções de soak; a escala de pools grandes e uma execução completa do ZTS ainda estão em aberto.
Licença: CDDL, como o OpenZFS upstream; as exceções são indicadas nos próprios arquivos-fonte.
Plataformas: Linux; testado em uma VM de laboratório Ubuntu com QEMU/KVM, em builds baseados no zfs-2.4.4 e no master atual.

O que resolve

Em um pool que atende máquinas virtuais e contêineres em execução, mudar a redundância do RAIDZ ou remover um disco hoje exige uma janela de manutenção: mover os guests, exportar o pool, reconstruir e colocar tudo de volta. A expansão de RAIDZ do OpenZFS 2.3 acrescentou apenas o aumento de largura online. O objetivo deste trabalho é mudar a geometria de um pool ativo in loco, usando só o espaço livre do próprio pool e preservando snapshots e clones.

Principais recursos

zpool reparity aumenta ou reduz a paridade do RAIDZ in loco (raidz1 ↔ raidz2 ↔ raidz3); com --online os datasets continuam montados, e --async, --status e --cancel executam a operação em segundo plano.
Uma tabela de épocas de layout por vdev, por trás de uma única feature flag nova (nome provisório com.openzfs:raidz_parity_epochs): cada bloco é lido e reconstruído com a geometria com que foi gravado.
Commit fail-closed: a nova paridade só passa a valer depois que um censo não encontra mais nenhum bloco com a antiga; caso contrário, a varredura é retomada, inclusive após um crash.
Ferramentas zhack offline: remoção de um disco de um vdev RAIDZ (N → N−1), reconfiguração com snapshots e clones, recálculo de checksums e recompressão dos dados existentes; as duas últimas são experimentais.
Testes funcionais ZTS e páginas man para os novos comandos; um RFC e uma série empilhada de branches preparada para revisão upstream.

Como funciona

Cada vdev RAIDZ de nível superior ganha uma pequena tabela append-only de registros {start_txg, width, parity}, no mesmo formato dos registros já existentes da expansão de RAIDZ. A geometria de um bloco é escolhida pelo txg de nascimento, então blocos antigos e novos coexistem. Uma varredura limitada e retomável após crash regrava os blocos existentes pelo copy-on-write comum. A codificação de linhas do RAIDZ, o formato dos ponteiros de bloco e o ashift não mudam.

zpool reparity [--online | --async | --status | --cancel] [--target N] pool

Requisitos

Um pool com vdevs RAIDZ. A feature flag é incompatível e fica ativa com a primeira reconfiguração.
Compilado a partir do código-fonte, como o OpenZFS. Os branches ozfs-pr/1-parity-epochs-recon, ozfs-pr/2-reparity-command e ozfs-pr/3-reshape-toolkit se baseiam no master, e feat/raidz-* no zfs-2.4.4.
A remoção de um disco e as ferramentas zhack offline exigem o pool exportado.

Esta página resume o README e a documentação do repositório em outubro de 2026. A fonte de referência é o próprio repositório.

Repositório no GitHub ← Todos os projetos