Copy-on-Write: ZFS, Btrfs e APFS na Arquitetura de Armazenamento

A arquitetura Copy-on-Write redefiniu a confiabilidade de dados ao banir a mutação destrutiva de blocos no armazenamento.

Ao gravar modificações exclusivamente em setores livres, sistemas modernos preservam versões históricas e eliminam escritas rasgadas.

Essa abordagem viabiliza snapshots instantâneos em tempo constante e auto-cura criptográfica contra corrupção silenciosa de hardware.

A mecânica da mutabilidade: in-place overwrite vs Copy-on-Write

Sistemas tradicionais sobrescrevem blocos físicos existentes no disco, enquanto sistemas Copy-on-Write nunca alteram blocos já alocados. Toda modificação gera uma nova gravação em espaço livre, preservando os dados originais até a transição atômica de ponteiros.

Em sistemas convencionais como ext4 e XFS, os arquivos são vinculados a endereços lógicos fixos no disco. Quando um aplicativo atualiza um registro, o sistema operacional sobrescreve os mesmos setores físicos com os novos bytes.

Para mitigar panes elétricas durante a escrita, sistemas legados usam journaling de metadados. No modo padrão data=ordered, o journal grava apenas metadados antes de atualizar o arquivo no endereço final.

Se o fornecimento de energia for interrompido no meio de uma página de 8 KiB, ocorre o fenômeno da escrita rasgada. Os metadados podem apontar para um bloco inconsistente contendo metade de dados antigos e metade de dados novos.

A recuperação dessas falhas exige a execução do utilitário fsck durante o boot. Em volumes com dezenas de terabytes, essa varredura pode paralisar a infraestrutura durante horas.

O paradigma Copy-on-Write (CoW) adota uma premissa estritamente não-destrutiva. Um bloco alocado torna-se imutável até que nenhuma referência aponte para ele.

Quando ocorre uma modificação, o subsistema aloca novos blocos livres para receber o payload atualizado. Em seguida, novos nós de metadados são criados para referenciar os novos endereços.

MUTAÇÃO IN-PLACE (ext4) vs ARQUITETURA COPY-ON-WRITE (ZFS/Btrfs):

Modelo In-Place (ext4):
[Dado Original: Bloco A] ---- sobrescrita direta ----> [Dado Modificado: Bloco A]
(Risco de corrupção estrutural se houver queda de energia no meio da escrita)

Modelo Copy-on-Write (ZFS/Btrfs):
[Dado Original: Bloco A] (preservado intacto e imutável)
           \
            +---> [Dado Modificado: Bloco B] (gravado em novo espaço livre)

Nenhum dado pré-existente é alterado durante a operação de escrita. Se uma falha de hardware ocorrer enquanto os novos blocos estão sendo preenchidos, o estado anterior permanece íntegro e legível.

Atomicidade física sem fsck: Uberblock do ZFS e Superblock do Btrfs

Sistemas CoW garantem integridade transacional sem fsck atualizando o ponteiro raiz do sistema de arquivos em uma única operação atômica de hardware. O novo estado só se torna visível após todos os blocos de dados e metadados intermediários estarem gravados e persistidos no disco.

Essa propriedade é chamada de consistência transacional e transforma o sistema de arquivos em um log estruturado em árvore. A raiz da árvore aponta para todo o grafo de diretórios, nós e folhas de dados.

No OpenZFS, essa transição atômica é comandada pelo Uberblock. Cada vdev armazena um anel estático de 128 estruturas de Uberblock de 1 KiB em seus cabeçalhos de proteção física.

A cada ciclo de sincronização de transação, o ZFS grava o novo Uberblock na posição seguinte do anel circular. Esse registro contém o contador de transação global e o ponteiro para a raiz do grafo de metadados.

Na montagem do pool, o kernel varre os 128 registros. Ele seleciona o Uberblock mais recente com checksum criptográfico válido. Se a máquina desligou antes do flush, o sistema monta a versão anterior sem corrupção.

ESTRUTURA DO UBERBLOCK NO OPENZFS (ANEL CIRCULAR):

[VDEV Label 0] -> [Uberblock 0] [Uberblock 1] ... [Uberblock 127]
                        |
                        +---> ub_txg (Identificador sequencial da transação)
                        +---> ub_rootbp (Ponteiro físico para o nó raiz do pool)
                        +---> ub_checksum (Validação independente SHA-256/Fletcher4)

O Btrfs implementa uma estratégia análoga com anéis de superblocks espelhados em offsets fixos do disco. O commit de transação força um flush de hardware e atualiza atomicamente o identificador de geração.

Como consequência, tanto o ZFS quanto o Btrfs descartam por completo o conceito de verificação corretiva offline. O sistema de arquivos está permanentemente consistente no disco após qualquer interrupção não programada.

Snapshots atômicos em O(1) e o compartilhamento de extents

Snapshots em sistemas Copy-on-Write são criados em tempo constante O(1) porque apenas duplicam e congelam o ponteiro raiz da árvore de metadados. Eles consomem zero bytes físicos adicionais no instante da criação, divergindo apenas conforme novas gravações alocam novos blocos.

Em sistemas legados de arquivos, criar um snapshot exige cópias em nível de bloco através de camadas LVM ou clones lentos de arquivos. Esse processo consome largura de banda maciça de I/O e satura o barramento de dados.

No modelo CoW, um snapshot consiste em registrar um ponteiro imutável para a raiz da árvore em um dado instante no tempo. O comando executa em microssegundos, independentemente de o volume conter 10 gigabytes ou 500 terabytes.

Após o congelamento da raiz histórica, o volume de produção continua operando normalmente. Quando um arquivo existente é editado, o sistema aloca novos blocos para conter as alterações.

A árvore ativa passa a apontar para os novos blocos alocados. A árvore do snapshot continua apontando estaticamente para os blocos antigos que não foram tocados.

O consumo de espaço em disco do snapshot é exatamente proporcional à divergência de dados entre as versões. Se nenhum arquivo for alterado, o consumo adicional de armazenamento permanece nulo.

A desalocação de blocos respeita uma contagem de referências ativas por extent. Um bloco físico só retorna ao espaço livre quando a árvore ativa e todos os snapshots que o referenciam forem destruídos.

Essa mecânica permite manter centenas de pontos de restauração por volume sem sobrecarregar a capacidade de armazenamento da infraestrutura.

Reflinks de arquivo e isolamento instantâneo em sandboxes

Reflinks criam clones de arquivos em microssegundos compartilhando os mesmos blocos físicos subjacentes sem copiar bytes no disco. O sistema operacional gera um novo inode apontando para os extents existentes, adiando a duplicação real para o momento em que algum bloco for alterado.

Enquanto links rígidos compartilham o mesmo número de inode e propagam alterações mutuamente, reflinks criam arquivos totalmente independentes. Modificar um clone reflink não altera o arquivo de origem.

No ambiente Linux, a criação de reflinks é padronizada pela chamada de sistema ioctl(FICLONE). O utilitário cp suporta essa operação nativa através da flag --reflink=always.

#include <fcntl.h>
#include <linux/fs.h>
#include <sys/ioctl.h>
#include <unistd.h>

int clone_file_reflink(const char *src_path, const char *dst_path) {
    int src_fd = open(src_path, O_RDONLY);
    if (src_fd < 0) return -1;

    int dst_fd = open(dst_path, O_WRONLY | O_CREAT | O_EXCL, 0644);
    if (dst_fd < 0) { close(src_fd); return -2; }

    /* Compartilha extents físicos em O(1) sem cópia de bytes */
    int ret = ioctl(dst_fd, FICLONE, src_fd);

    close(src_fd);
    close(dst_fd);
    return ret;
}

No ecossistema macOS sob o formato APFS, essa funcionalidade é exposta pela chamada de sistema clonefile(). Duplicar uma biblioteca de 50 gigabytes na interface gráfica acontece de maneira instantânea.

Essa técnica transforma o gerenciamento de ambientes de desenvolvimento e execução de código. Em plataformas como o MaxVision Code, agentes autônomos precisam rodar suites de teste e compilações em sandboxes efêmeras totalmente isoladas.

Copiar repositórios massivos contendo gigabytes de código e dependências em disco tradicional cria gargalos severos de I/O. Utilizando reflinks sobre Btrfs ou APFS, o orchestrator clona o repositório inteiro em tempo quase zero.

Cada agente trabalha sobre uma cópia privativa com isolamento estrito. Apenas os arquivos editados pelo agente durante a execução consomem blocos reais de armazenamento.

Terminada a execução da tarefa, a destruição do ambiente temporário desaloca apenas a fração diferencial de blocos gerada durante o run.

Árvores de Merkle e auto-cura contra silent data corruption

Árvores de Merkle armazenam o checksum criptográfico de cada bloco filho dentro do seu bloco pai na hierarquia de metadados. Isso impede que corrupções silenciosas de disco passem despercebidas, viabilizando a auto-cura imediata através da leitura de blocos íntegros em réplicas redundantes.

Discos rígidos e unidades SSD sofrem com o fenômeno da corrupção silenciosa de dados, comumente denominada bit rot. Falhas no firmware da controladora, ruído térmico e setores defeituosos podem alterar bits gravados sem emitir erro de leitura.

O estudo seminal da USENIX FAST '08 avaliou 1,53 milhão de discos. A pesquisa comprovou 400.000 corrupções silenciosas em 32 meses. Cerca de 8,5% dos discos SATA desenvolveram anomalias que passaram sem aviso pelo hardware.

Controladores RAID convencionais e sistemas com journaling não detectam essa falha porque não calculam checksums de dados de usuário. Eles leem o bloco corrompido, assumem que o hardware é confiável e entregam bytes inválidos à aplicação.

O OpenZFS e o Btrfs resolvem essa vulnerabilidade estruturando o armazenamento como uma grande Árvore de Merkle. Cada ponteiro de bloco guarda os endereços físicos e o hash criptográfico do bloco para o qual ele aponta.

ARQUITETURA DE ÁRVORE DE MERKLE EM SISTEMAS COPY-ON-WRITE:

              [Uberblock / Raiz]
              Contém Checksum do Nó A
                     /
                    v
             [Nó de Metadados A]
         Contém Checksums de B1 e B2
             /                 \
            v                   v
     [Folha de Dados B1]  [Folha de Dados B2]

Quando uma aplicação solicita a leitura de um arquivo, o sistema calcula o checksum do bloco recebido usando algoritmos velozes como Blake3, SHA-256 ou Fletcher4. Esse valor é comparado com o hash armazenado no nó pai.

Se os checksums coincidirem, o bloco é entregue ao espaço de usuário com garantia matemática de integridade. Se os valores divergirem, o sistema de arquivos bloqueia o dado corrompido e inicia a auto-cura.

O subsistema busca a cópia idêntica do bloco em um disco de espelhamento ou reconstrói o payload através dos blocos de paridade RAID-Z. O dado correto é devolvido à aplicação sem emitir erro de I/O.

Em segundo plano, o driver grava imediatamente o bloco restaurado no disco defeituoso. Essa rotina força a controladora do drive a remapear o setor físico avariado sem intervenção humana.

Gargalos do CoW: fragmentação, amplificação de escrita e cargas OLTP

Sistemas Copy-on-Write sofrem com fragmentação intensa e alta amplificação de escrita quando submetidos a modificações aleatórias frequentes em arquivos grandes. Bancos de dados relacionais e máquinas virtuais degradam a vazão de leitura sequencial se não forem ajustados com políticas específicas de alocação.

Como cada modificação aloca um novo bloco em um setor arbitrário do disco, arquivos densamente alterados perdem a contiguidade física. Em bancos de dados como PostgreSQL e MySQL InnoDB, essa dispersão espacial reduz a eficiência de varreduras sequenciais.

Outro desafio crítico é a amplificação de escrita. Em gravações síncronas de 4 KiB, a atualização de ponteiros propaga-se em cascata. Isso pode forçar gravações adicionais até a raiz.

Em cargas de trabalho desfavoráveis, a razão entre bytes fisicamente gravados no dispositivo e bytes solicitados pela aplicação pode atingir fatores elevados. Esse comportamento reduz a vida útil de memórias flash em drives SSD.

Engenheiros de infraestrutura contornam essas limitações adotando configurações adequadas para cada cenário:

• Alinhamento de recordsize no OpenZFS: configurar o tamanho de bloco do dataset para corresponder à página do banco (8 KiB no PostgreSQL e 16 KiB no MySQL).
• Uso do ZIL em discos dedicados: desviar escritas síncronas para SSDs de alta resistência (SLOG) para amortecer commits sem fragmentar o pool.
• Ativação da flag NoCoW no Btrfs: aplicar o comando chattr +C em diretórios de bancos de dados para permitir sobrescrita in-place, reduzindo fragmentação.
• Varreduras programadas de scrub: executar rotinas periódicas de leitura em segundo plano para validar a árvore de Merkle e corrigir desvios preventivamente.

Com esses ajustes de engenharia, sistemas de arquivos Copy-on-Write operam com alto desempenho mantendo a segurança de dados intacta.

Comparativo técnico: OpenZFS, Btrfs, APFS e ext4

A escolha do sistema de arquivos depende do equilíbrio entre integridade criptográfica, suporte a volumes e flexibilidade de kernel. O OpenZFS domina em integridade e grandes pools. O Btrfs oferece flexibilidade no Linux, o APFS otimiza SSDs Apple e o ext4 prioriza latência previsível.

A tabela a seguir sintetiza as principais diferenças arquiteturais e operacionais entre os três maiores expoentes Copy-on-Write e o formato tradicional com journaling:

Enquanto o OpenZFS continua insubstituível para armazenamento de alta confiabilidade em servidores corporativos, o Btrfs se destaca na flexibilidade de reflinks para desenvolvedores Linux. O APFS consolida o ecossistema flash da Apple. Já o ext4 atende servidores de banco de dados onde a simplicidade in-place é prioritária.

Perguntas Frequentes sobre Sistemas Copy-on-Write

O que acontece com os dados antigos após uma escrita Copy-on-Write?

Os dados originais permanecem inalterados no bloco físico onde foram gravados inicialmente. Se nenhum snapshot referenciar esse bloco, ele é marcado como espaço livre após o commit atômico da transação. Caso exista algum snapshot ativo apontando para ele, o bloco continua protegido no disco até que o snapshot seja removido.

Por que sistemas CoW não precisam rodar fsck após uma queda de energia?

A consistência do sistema de arquivos é mantida em tempo integral através da comutação atômica do ponteiro raiz. O novo estado só é ativado quando todos os dados e nós da árvore estão completamente persistidos no armazenamento. Em caso de corte abrupto de energia, o sistema simplesmente descarta a transação incompleta e monta o estado anterior válido.

Reflink consome o dobro de espaço ao duplicar um arquivo de 10 GB?

Não, a criação de um reflink consome zero bytes adicionais de espaço de dados no momento da execução. O sistema cria apenas um novo inode que aponta para os mesmos blocos físicos do arquivo original. O consumo real de disco só aumenta conforme um dos arquivos sofrer modificações pontuais em seus bytes.

Qual a diferença entre journaling tradicional e Copy-on-Write?

Sistemas com journaling gravam um log prévio de metadados e depois sobrescrevem o arquivo no mesmo local físico do disco. Sistemas CoW nunca sobrescrevem o local original, gravando alterações em novos blocos livres antes de atualizar a raiz. Isso elimina escritas rasgadas e garante a integridade tanto dos dados quanto dos metadados.

Por que bancos de dados relacionais sofrem em sistemas de arquivos CoW?

Bancos como PostgreSQL realizam escritas aleatórias frequentes em arquivos monolíticos de tabelas e índices. Em sistemas CoW, essas atualizações quebram a contiguidade dos blocos e aumentam a amplificação de escrita. O ajuste do tamanho de registro do dataset ou o uso de diretórios com a flag NoCoW evita essa degradação de desempenho.