Um bug de corrupção de dados no OpenZFS?

Artigo original ↗ Discussão no Hacker News ↗

Uma rara condição de corrida no OpenZFS pode fazer com que arquivos sejam silenciosamente preenchidos com zeros durante certas operações de cópia, sem que a corrupção tradicional seja detectável por scrubs, levantando preocupações para usuários que dependem do ZFS para integridade de dados. Comentadores enfatizam que o bug é difícil de acionar e provavelmente não afetou a maioria dos sistemas, mas o usam como ponto de partida para destacar estratégias robustas e testadas de backup, armazenamento externo seletivo e a importância de entender como recursos como arquivos esparsos e snapshots interagem com cargas de trabalho reais. O debate também aborda alternativas como bcachefs, as limitações dos modos RAID do Btrfs e o impacto do licenciamento e da gestão da Oracle na adoção do ZFS no Linux.

Impacto do bug do OpenZFS

  • Descrito como uma condição de corrida muito rara, difícil de reproduzir na prática.
  • Os sintomas seriam óbvios em cargas de trabalho com muitas gravações/movimentações (por exemplo, árvores de build contendo de repente arquivos preenchidos com zeros).
  • Verificar bcloneused/bclonesaved é apontado como não sendo um teste confiável; bclones eram apenas um gatilho.
  • A corrupção não é um dano tradicional em disco: cp lê zeros e os grava, e o ZFS os armazena corretamente, então scrubs e comparações byte a byte com backups não detectariam isso.
  • Dada a idade do bug e a ausência de relatos de grandes usuários de ZFS, vários comentários argumentam que o risco no mundo real é baixo.

Confiabilidade e teste de backups

  • Ênfase forte no fato de que backups frequentemente falham de forma silenciosa: ferramentas podem pular arquivos, parar no meio da execução ou registrar logs de forma ruim.
  • Conselho:
    • Teste restaurações regularmente, inclusive de sistemas que você raramente acessa.
    • Faça com que alguém além do especialista execute as restaurações, para validar a documentação e as ferramentas.
    • Mantenha scripts e ferramentas de reparo atualizados.
    • Verifique os backups após a execução (tamanhos, capacidade de descriptografar/desempacotar, hashes quando possível).
    • Use pelo menos duas implementações diferentes de backup.
  • Backups de bancos de dados são destacados como especialmente complicados; snapshots do sistema de arquivos sozinhos não são suficientes para consistência transacional.

NAS doméstico e estratégias de backup de grandes volumes de dados

  • Muitos argumentam que “NAS doméstico médio” não significa 40 TB; para a maioria, apenas um subconjunto (fotos, documentos) precisa de backup na nuvem.
  • Estratégias mencionadas:
    • Nuvem (Backblaze, S3 Glacier/Deep Archive, Hetzner Storagebox, B2) com hierarquização por importância.
    • Segundo NAS ou servidor fora do local (família/amigos) usando rsync/ZFS send/syncthing por VPN/Tailscale/Nebula.
    • Armazenamento frio em HDD/SSD externo, rotacionado e majoritariamente offline.
    • Fita LTO para conjuntos de dados grandes e críticos, com alguns descrevendo-a como economicamente vantajosa no longo prazo, mas operacionalmente trabalhosa e ruidosa.
  • Regras gerais: invista cerca de 3× o custo do seu armazenamento “quente” em backups; priorize várias cópias não redundantes em vez de uma única cópia em RAID.

Arquivos esparsos e abstrações de sistema de arquivos

  • Debate sobre se arquivos esparsos e SEEK_HOLE/SEEK_DATA foram um erro de design ou uma otimização útil.
  • Alguns veem arquivos esparsos como um vazamento de detalhes de nível de bloco para o espaço do usuário e uma complexidade adicional que pode causar bugs como este.
  • Outros argumentam que eles são essenciais para cargas de trabalho como torrents, bancos de dados, imagens de VM e deduplicação.
  • Discussão sobre fallocate, mmap e como diferentes sistemas de arquivos e semânticas de COW interagem com pré-alocação e fragmentação.

Sistemas de arquivos alternativos e política de licenciamento

  • Observou-se que bugs recentes e graves estavam no OpenZFS, não no ZFS fechado da Oracle, mas a Oracle efetivamente abandonou o Solaris.
  • Longo debate sobre CDDL vs GPL: a incompatibilidade complica a integração do OpenZFS ao Linux; alguns argumentam que o risco jurídico é exagerado, outros veem a Oracle como uma ameaça séria.
  • O envio do ZFS pela Ubuntu por longo tempo sem ação legal é citado, mas alguns acham que ações judiciais futuras ainda são possíveis.
  • bcachefs é visto por alguns como uma alternativa promissora nativa do Linux (discos heterogêneos, redundância estilo RAID-5/6, consciente de SMR), mas outros alertam que ele ainda é jovem, com pouca exposição no mundo real e relatos de corrupção.