Lançado o ZFS 2.3, com suporte a expansão de RAIDZ

 (github.com/openzfs)
1 pontos por GN⁺ 2025-01-15 | 1 comentários | Compartilhar no WhatsApp
  • O OpenZFS 2.3.0 traz como principal recurso o RAIDZ Expansion, que permite adicionar novos dispositivos a um pool RAIDZ existente para aumentar a capacidade sem downtime
  • O Fast Dedup melhora significativamente o desempenho do recurso de desduplicação existente, junto com outras melhorias de performance em toda a base de código
  • O Direct IO permite ignorar o ARC em operações de leitura/gravação, mirando cenários como dispositivos NVMe, em que o cache pode prejudicar a eficiência
  • Foram adicionados saída JSON opcional para comandos mais usados, suporte a nomes de arquivos e diretórios de até 1023 caracteres e correções importantes de bugs que tratam problemas de versões anteriores
  • O suporte abrange kernels Linux 4.18~6.12 e FreeBSD 13.3, 14.0~14.2, e 134 pessoas participaram deste ciclo de lançamento

O que mudou no OpenZFS 2.3.0

  • O OpenZFS 2.3.0 foi atualizado com foco em expansão de armazenamento, desempenho de desduplicação, caminho de entrada/saída, formato de saída de comandos e suporte ao comprimento de nomes de arquivos
  • A tag de lançamento é zfs-2.3.0 e inclui as mudanças desde o OpenZFS 2.2.0

Expansão de armazenamento e melhorias de desempenho

  • RAIDZ Expansion permite adicionar novos dispositivos a um pool RAIDZ existente para aumentar a capacidade de armazenamento sem downtime
  • Fast Dedup é uma grande atualização de desempenho do recurso de desduplicação existente no OpenZFS
  • Direct IO permite ignorar o ARC em operações de leitura/gravação
    • O objetivo é melhorar o desempenho em situações como dispositivos NVMe, em que o cache pode atrapalhar a eficiência
  • Também foram incluídas várias melhorias de desempenho em toda a base de código

Saída de comandos e comprimento de nomes

  • JSON adiciona saída JSON opcional aos comandos mais usados
  • Long names oferece suporte a nomes de arquivos e diretórios de até 1023 caracteres

Estabilidade, plataformas e contribuições

  • Inclui correções importantes de bugs que tratam problemas relatados em versões anteriores
  • Plataformas suportadas:
    • kernels Linux 4.18~6.12
    • FreeBSD 13.3, 14.0~14.2
  • 134 contribuidores participaram deste ciclo de lançamento

Documentação e changelog

Mudanças nas opções de módulo

  • Todas as opções e seus alvos de controle estão organizados na documentação de module parameters
  • As novas opções de módulo incluem itens relacionados a expansão de RAIDZ, log de desduplicação, Direct IO, allocator, scrub e resilver
    • Ex.: raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Opção de módulo removida:
    • zfetch_array_rd_sz
  • Opções de módulo alteradas:
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-15
Opiniões no Hacker News

  • A expansão de RAIDZ no ZFS, preparada há anos, finalmente entrou
    Os principais recursos são: expansão de RAIDZ, que permite adicionar dispositivos a um pool RAIDZ existente para aumentar a capacidade sem interrupção; deduplicação rápida, que aumenta bastante o desempenho da deduplicação no OpenZFS; E/S direta, que contorna o ARC para melhorar o desempenho em ambientes onde cache pode ser ineficiente, como NVMe; saída JSON opcional para comandos usados com frequência; e suporte a nomes de arquivos e diretórios de até 1023 caracteres

    • Mais precisamente, significa que é possível anexar um novo dispositivo, ou seja, um disco, a um vdev RAIDZ existente
    • Se você roda Proxmox sobre ZFS e NVMe, fico curioso se vale a pena ativar E/S direta quando a versão 2.3 for distribuída
      Queria entender para que tipo de uso esse recurso é indicado
    • Os quatro primeiros parecem mudanças realmente grandes
    • Ainda assim, parece que a remoção de vdev ainda deve ser considerada impossível
    • Fico curioso sobre o quanto esse recurso foi bem testado junto com criptografia
      Também me pergunto se a equipe do ZFS realmente trata criptografia como prioridade de primeira classe
      O ZFS no Linux herdou muito da reputação do ZFS no Solaris, mas quem o usa em produção precisa olhar com bastante atenção o rastreador de issues para enxergar a realidade

  • Não entendo como o Windows, de longe a maior plataforma de PC em número de usuários, ainda não tem uma resposta ao ZFS
    A Microsoft teve o WinFS e depois o ReFS, mas eles foram ficando em segundo plano; o desenvolvimento continua e algumas partes aparecem ocasionalmente no Win11, mas não se vê um lançamento oficial
    Alguns indivíduos estão tentando o grande trabalho de criar uma camada de compatibilidade com ZFS, mas isso ainda está longe de ser maduro ou utilizável na prática
    Não sei como o Windows ainda usa um sistema de arquivos de 32 anos

    • Para ser sincero, a situação do Linux também não é muito melhor
      O ZFS tem problemas de licença com o Linux, o que impede uma integração completa, e o Btrfs está em desenvolvimento há 15 anos, mas ainda não alcança o ZFS em recursos e estabilidade
      A maioria das distribuições Linux ainda usa por padrão o ext4, de 19 anos, e o ext4 na verdade está mais para extensões sobre o ext2, que tem a mesma idade do NTFS
      Para ser justo, poucos componentes de um sistema operacional são tão importantes quanto o sistema de arquivos, e muita gente prefere não tocar em um sistema de arquivos que não tenha sido comprovado por mais de 10 anos em ambientes de produção
    • O motivo é simples. A maior parte do peso que o sistema de arquivos teria de carregar é assumida pelo hardware de armazenamento empresarial sobre o qual esse sistema de arquivos fica
      Recursos necessários como snapshots, deduplicação em nível de bloco, tecnologia de armazenamento de objetos, RAID/resiliência e redimensionamento são responsabilidade dos equipamentos de storage
      Appliances modernos de armazenamento são quase magia negra, então o NTFS não precisa necessariamente de mais recursos
      Basta acessá-los de forma transparente via NAS/SAN ou armazenar volumes NTFS sobre uma caixa de discos competente
      No mundo Linux, nas áreas avançadas, há Lustre e GPFS, e o ZFS em geral se encaixa em usos em que desempenho não é o ponto central, mas resiliência é necessária
    • Também não há uma resposta equivalente ao ZFS no kernel Linux mainline
      Acho que é porque é difícil e arriscado, enquanto a recompensa geralmente se limita a respeito técnico
    • Como usuário final que usa Windows e Linux, mas não usa ZFS, fico curioso sobre o que estou perdendo
    • O OpenZFS para Windows chegou ao estado de release candidate (rc11), e ainda há alguns bugs restantes em torno da montagem de volumes
      Não são graves, mas por enquanto é melhor evitar criptografia, e o ritmo de desenvolvimento é rápido, com novos release candidates saindo a cada poucas semanas para corrigir os problemas restantes
      Se você combinar isso com Storage Spaces para agrupar discos de tipos ou tamanhos diferentes e definir localização, redundância e tiering por Space, o Windows agora se torna uma plataforma avançada de armazenamento
      Usando Windows Server, por exemplo as edições baratas 2022/2025 Essentials, também é possível usar SMB Direct/RDMA com desempenho de até 10 Gbyte/s na LAN e sobre discos rígidos virtuais .vhdx, tornando-se uma alternativa mais rápida e sem configuração em relação ao iSCSI
      Por isso portei o napp-it cs, uma GUI web para ZFS, do Solaris para o Windows, para gerenciar Storage Spaces, ZFS e servidores OpenZFS remotos como o Proxmox; o uso não comercial é gratuito

  • Gosto do fato de terem feito o recurso de expansão de forma bem conservadora
    A expansão não só é totalmente transparente e pode ser retomada, como também mantém a redundância durante todo o processo
    Mas há uma pequena ressalva que as pessoas precisam saber
    Mesmo depois que a expansão termina, os blocos existentes mantêm a proporção antiga entre dados e paridade. Por exemplo, um RAIDZ2 de 5 discos fica distribuído em um conjunto maior de discos mantendo 3 dados para 2 paridades
    Novos blocos são gravados com a nova proporção entre dados e paridade. Por exemplo, se um RAIDZ2 de 5 discos for expandido uma vez para 6 discos, passa a ser 4 dados para 2 paridades

    • Não sei se isso é realmente uma ressalva. Significa apenas que os dados existentes podem permanecer em um layout não ideal
      Ainda assim, os benefícios do RAIDZ N continuam os mesmos: mesmo que até N discos falhem completamente, o pool continua funcionando
    • Essa ressalva é um comportamento totalmente esperado. Em geral, deve-se assumir que recursos do ZFS não reescrevem blocos existentes
      Por exemplo, mudanças de configuração também se aplicam apenas aos dados novos
    • Sinceramente, é uma ressalva bem grande
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Aqui, ___ é espaço vazio. Se você adicionar um disco e expandir, logicamente poderia esperar algo assim
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Mas, pelo que entendi, na prática a expansão fica assim
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Aqui, os blocos Dd1~3 são simplesmente desperdiçados. Ou seja, mesmo adicionando um disco novo ao array, o espaço livre aumenta só 25%
      Por exemplo, se você originalmente tinha 24 TB de espaço utilizável com discos de 8 TB e 4 TB livres antes da expansão, depois da expansão o espaço livre passa a 5 TB
      Gostaria que alguém me dissesse que entendi errado. Se não for um mal-entendido, parece uma implementação bastante inútil

  • É uma grande notícia para usuários de ZFS. Talvez especialmente para usuários entusiastas e domésticos, mas ainda assim é grande
    Expansão de RAIDZ era um dos recursos mais pedidos há anos

    • Ainda não estou familiarizado com ZFS e não encontrei isso nas notas de lançamento, mas fico curioso se a expansão só funciona com discos do mesmo tamanho
      Gostaria de saber se é possível adicionar um disco maior ou menor, ou se todos os discos precisam ter o mesmo tamanho

  • Isto é expansão online. A expansão em si já era possível antes, mas era preciso derrubar o array
    Também era possível migrar para unidades maiores, mas era necessário substituí-las uma por vez e, naturalmente, a nova capacidade só ficava disponível depois que todas as unidades fossem atualizadas
    Até onde sei, reduzir um pool ainda não é possível. Então, se você adicionar um sexto disco a um pool de 5 discos, não dá para voltar para 5, mesmo que haja pouquíssimos dados

  • Finalmente!
    Agora também dá para fazer uma configuração de vdev único meio insana, no limite, como RAID-Z3 com 4 dos discos rígidos mais caros e de maior densidade que você consegue comprar hoje
    No começo, como há redundância equivalente a 3 discos, a taxa de uso efetivo do espaço é de apenas 25%, mas, à medida que a necessidade de espaço cresce, você pode comprar um disco por vez e expandir até algo em torno de 12 discos
    Com o tempo, os preços dos discos caem e, como os discos são adicionados em momentos diferentes, a probabilidade de falha também fica distribuída

    • Certo, mas veja também o comentário irmão
      Expandir o array não faz com que os dados existentes sejam armazenados de forma mais eficiente
      Para obter a nova proporção de paridade/dados, é preciso forçar a cópia dos dados e apagar a versão antiga ineficiente. Por exemplo, seria necessária uma ferramenta como esta [1]
      Pessoalmente, acho muito melhor comprar configurações RAID-Z completas separadamente e adicionar a nova configuração, ou substituir uma configuração antiga disco por disco
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Fico curioso para saber como o ZFS se compara ao btrfs
    Estou usando btrfs no meu home server agora, mas já passei por alguns problemas estranhos
    Estou pensando em migrar para ZFS, mas não quero cair na mesma situação

    • Usei btrfs pela primeira vez há 15 anos, por volta do Linux 2.6.33-rc4
      Em 3 dias apareceu um arquivo que eu não conseguia apagar, então parei de usar e depois encontrei o ZFS
      O ZFS também tinha alguns problemas menos graves, mas eu era estudante de ciência da computação na época e, comparados ao que enfrentei no btrfs, eles pareciam pequenos, então achei que conseguiria corrigi-los
      Nos 18 meses seguintes, resolvi todos os problemas que me incomodavam e enviei patches para o repositório ZFSOnLinux da época; esse esforço ajudou a tornar o ZFS utilizável em produção no Linux
      Desde então continuei usando ZFS, e ele tem funcionado bem
      Se o estado do btrfs fosse melhor, eu teria me tornado contribuidor do btrfs. Mas, além de o estado dele ser ruim na época, depois disso, sempre que tentei usá-lo para algo sério, continuei esbarrando em problemas, como erros ENOSPC frequentes mesmo ainda havendo espaço disponível
      Já o ZFS simplesmente funciona. Eu e muitas outras pessoas trabalhamos bastante para fazê-lo funcionar bem
      A maior diferença é que o ZFS tinha uma base muito sólida, graças a uma excelente infraestrutura de testes de regressão
      A versão em espaço de usuário executa o código de forma aleatória para encontrar bugs antes que eles estourem em produção, e um conjunto de testes é rodado para cada alteração proposta para filtrar bugs
      O ZFS também tem mais pessoas revisando mudanças propostas do que outros sistemas de arquivos. Os desenvolvedores do Btrfs também costumam dizer que há uma grande diferença de pessoal entre os dois sistemas de arquivos; lembro que falavam em algo como 6 vezes
      De todo modo, é raro alguém se arrepender de usar ZFS, então você provavelmente vai gostar
    • O ZFS é usado em ambientes de produção há quase 20 anos
      Segundo a documentação do BTRFS, o BTRFS ainda não é totalmente adequado para produção: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Alguns casos de uso simples podem ser considerados bons o suficiente para produção com BTRFS, mas os resultados variam conforme o ambiente
    • O btrfs tem objetivos parecidos com os do ZFS, mas é muito menos maduro
      Usei-o na partição raiz porque não precisava de DKMS, mas tive muitos problemas
      Eu o usava de forma bem simples, apenas em espelho, mas um dia, quando um dos drives do array teve problema, o btrfs não aguentou direito
      Pelo que lembro, ele remontou tudo como somente leitura e, por padrão, não operava em modo degradado
      Até mesmo mdraid, que não tem recursos como checksum, teria sido melhor
      O ZFS também marca o array como com falha, mas obviamente permite continuar usando
      Perdi a confiança porque o comportamento padrão não era de RAID; ou seja, a parte R, de reler os dados, basicamente estava ausente
      Desde que migrei para ZFS não tive problemas, e a comunidade e as boas ferramentas também são muito maiores
    • Usei Btrfs por alguns anos e o abandonei há alguns anos
      Também tive uma ou duas coisas estranhas no Btrfs, mas no fim consegui recuperar tudo
      No geral, a flexibilidade do Btrfs era boa, mas na maioria dos casos eu o achava lento demais
      Agora uso ZFS no Arch Linux e, até aqui, no geral não tive problemas
      Há também mais ajustes e formas de otimizar o desempenho
      Um conselho: com ZFS, vale a pena pesquisar e testar bastante. Há uma pequena curva de aprendizado, mas para mim a migração valeu a pena

  • É bom ver que agora existe bypass do ARC para desempenho em NVMe
    O ZFS tende a não aproveitar bem todo o potencial do NVMe
    A expansão online também pode ser interessante
    Tentei usar ZFS em um banco de dados muito movimentado e fui bastante afetado por um bug de fragmentação
    A única forma de recuperar o desempenho parecia ser copiar os dados para fora do volume, destruir o volume e copiá-los de volta
    Agora talvez seja possível expandir o zpool e depois copiar o tablespace dentro do mesmo volume para reduzir a fragmentação

  • Também vale notar que o TrueNAS já oferece suporte a esse recurso[0]
    Parece que provavelmente usa a 2.3.0rc3; não sei quanto à estabilidade, mas estou bem animado
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • Alguém consegue explicar por que usar algo como ZFS em casa?

    • Para mim, os bons motivos são estes:
      Checksums: em uso doméstico, a qualidade do hardware costuma ser menor, então isso é ainda mais importante. Há muitos motivos para dados incorretos serem gravados — controladores com defeito, cabos ruins, HDs mantidos em temperaturas acima do recomendado etc. — e, se houver redundância, o ZFS lida bem com isso automaticamente
      Snapshots: muito úteis para fazer backups e voltar rapidamente a versões antigas de arquivos quando você comete algum erro
      Tranquilidade: em comparação com as alternativas, sinto que o ZFS é fácil de usar e dificulta cometer erros que levem à perda de dados. Por exemplo, se você estiver substituindo um drive com defeito e acidentalmente remover o drive errado, deixando o pool inutilizável, basta colocá-lo de volta e tudo volta como se nada tivesse acontecido
      Hoje o mdadm talvez também seja diferente, mas quando usei alguns anos atrás eu vivia preocupado em cometer algum erro destrutivo
    • Dando uma resposta que outros não deram: ZFS é bom para armazenar jogos da Steam
      Ao configurar recordsize=1M e compression=zstd, muitas vezes dá para armazenar cerca de 33% mais jogos no mesmo espaço
      Um amigo usa ZFS para armazenar jogos da Steam em alguns HDs. E deu ao ZFS um SSD como L2ARC
      O ZFS coloca automaticamente em cache no SSD os jogos executados com frequência, para que carreguem mais rápido
      Quando seus jogos favoritos mudam, o ZFS se adapta automaticamente e passa a colocar esses jogos em cache no SSD
    • Uso zrepl para replicar todo o sistema de arquivos para um NAS local a cada 10 minutos
      Isso já me ajudou muito uma vez quando um WD_BLACK SN850 morreu de repente [1]
      Também recuperou código que eu perdi por um erro clássico de git
      Perder dados por erro do usuário ou falha de um único dispositivo não deveria mais ser possível. Nós temos a tecnologia para isso
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Há vários motivos, mas para mim os principais são confiabilidade e portabilidade
      Não existe outro sistema de arquivos moderno com checksums e autorrecuperação que possa ser lido e escrito em Linux, FreeBSD, Windows e macOS
      Snapshots, isto é, ambientes de boot, o Btrfs também suporta. Minha instalação Linux usa isso para não precisar me preocupar com módulos de kernel de terceiros para ler o sistema de arquivos raiz
      O desempenho também não é excelente; se desempenho for sua principal preocupação no Linux, XFS é uma escolha melhor
    • É relativamente fácil, mas poderoso
      Antes eu usava MDADM + LVM + dm-crypt + ext4, e aquilo também funcionava, mas eram camadas demais e dava dor de cabeça
      Snapshots automáticos são muito fáceis e rápidos
      Também é fácil acessá-los quando você apaga um arquivo: sem precisar restaurar o snapshot inteiro, basta fazer cp a partir da pasta oculta .zfs/
      Estou rodando isso há anos com 6 discos de 8 TB. Como é RAIDZ2, até 2 discos podem morrer
      Se eu usaria isso em um único disco no desktop? Provavelmente não