Compartilhar via


Clonagem de blocos

Uma operação de clonagem de bloco instrui o sistema de arquivos a copiar um intervalo de bytes de arquivo em nome de um aplicativo. O arquivo de destino pode ser igual ou diferente do arquivo de origem.

Um sistema de arquivos gerencia os mapeamentos de Clusters e Extensões e pode executar a cópia alterando o número de cluster virtual (VCN) para mapeamentos de número de cluster lógico (LCN) como uma operação de metadados de baixo custo, em vez de ler e gravar os dados do arquivo subjacente. Isso permite que a cópia seja concluída mais rapidamente e gera menos E/S para o armazenamento subjacente. Além disso, vários arquivos agora podem compartilhar clusters lógicos após o clone do bloco, economizando capacidade ao não armazenar clusters idênticos várias vezes no disco.

Uma operação de clonagem de bloco não interrompe o isolamento fornecido entre os arquivos. Após a conclusão de um clone de bloco, as gravações no arquivo de origem não aparecem no destino ou vice-versa.

A clonagem de bloco está disponível somente no tipo de sistema de arquivos ReFS a partir do Windows Server 2016. A partir da atualização do Windows 11 Moment 5 (KB5034848) e versões posteriores do cliente Windows e builds do Windows Server, a clonagem de bloco ocorre nativamente em operações de cópia do Windows com suporte.

Clonagem de bloco no ReFS

A partir do Windows Server 2016, o ReFS implementa a clonagem de blocos remapeando clusters lógicos (ou seja, locais físicos em um volume) da região de origem para a região de destino. Em seguida, ele usa um mecanismo de alocação na gravação para garantir o isolamento entre essas regiões. As regiões de origem e destino podem estar nos mesmos arquivos ou em arquivos diferentes.

Essa implementação requer que os deslocamentos do arquivo inicial e final sejam alinhados aos limites do cluster. No ReFS a partir do Windows Server 2016, os clusters têm 4KB de tamanho por padrão, mas opcionalmente podem ser definidos como 64KB. O tamanho do cluster é um parâmetro de todo o volume definido no momento do formato.

Implicações de tamanho e desempenho do cluster

O tamanho do cluster de um volume ReFS afeta diretamente as características de desempenho e comportamento de clonagem de blocos:

  • Tamanho do cluster padrão: 4KB (recomendado para a maioria das cargas de trabalho)
  • Tamanho de cluster alternativo: 64 KB (apropriado para cargas de trabalho de E/S grandes e sequenciais)

O tamanho do cluster determina a granularidade na qual ocorrem operações de clonagem de blocos e cópia em escrita. Quando uma gravação é feita em uma região de arquivo que compartilha clusters com outro arquivo (após um clone de bloco), o ReFS usa um mecanismo de alocação na gravação que opera no nível do cluster:

  • Somente o cluster modificado é duplicado e gravado em um novo local físico
  • Clusters não modificados na mesma região permanecem compartilhados
  • Esse comportamento se aplica independentemente de a clonagem de bloco ter sido iniciada explicitamente por meio de FSCTL_DUPLICATE_EXTENTS_TO_FILE ou automaticamente pelo sistema (Windows 11 Moment 5 e posterior)

Considerações sobre desempenho

A escolha do tamanho do cluster tem implicações importantes para o desempenho e o consumo de espaço:

  • Clusters de 4KB: fornecem melhor eficiência de espaço para cargas de trabalho com gravações pequenas e aleatórias (intervalo de KB a MB), pois apenas 4KB são duplicados por cluster modificado. No entanto, isso pode resultar em operações de cópia em gravação mais frequentes.
  • Clusters de 64 KB: Reduzem a sobrecarga de metadados e melhoram o desempenho sequencial de E/S, mas podem resultar em até 64 KB sendo duplicados para cada gravação em uma região compartilhada, mesmo que a gravação seja menor que 64 KB.

O tamanho do cluster é determinado no momento do formato e não pode ser alterado sem reformatar o volume. Para verificar o tamanho atual do cluster de um volume ReFS, use o seguinte comando:

fsutil fsinfo refsinfo <volume>

Para volumes formatados pelo Windows automaticamente (como quando a clonagem de blocos é habilitada por padrão), o sistema usa o tamanho do cluster padrão de 4KB, a menos que explicitamente configurado de outra forma durante a criação do volume.

Restrições e observações

  • As regiões de origem e destino devem começar e terminar em um limite de cluster.
  • A região clonada deve ter menos de 4 GB.
  • A região de destino não deve se estender além do final do arquivo. Se o aplicativo quiser estender o destino com dados clonados, ele deverá primeiro chamar SetEndOfFile.
  • Se as regiões de origem e de destino estiverem no mesmo arquivo, elas não deverão se sobrepor. (O aplicativo pode continuar dividindo a operação de clone de bloco em vários clones de bloco que não se sobrepõem mais.)
  • Os arquivos de origem e de destino devem estar no mesmo volume do ReFS.
  • Os arquivos de origem e de destino devem ter a mesma configuração de Fluxos de Integridade (ou seja, fluxos de integridade devem ser habilitados em ambos os arquivos ou desabilitados em ambos os arquivos).
  • Se o arquivo de origem for esparso, o arquivo de destino também deverá ser esparso.
  • A operação de clone de bloco quebrará os bloqueios oportunistas compartilhados (também conhecidos como bloqueios oportunistas de nível 2).
  • O volume ReFS deve ter sido formatado com o Windows Server 2016 ou posterior e, se o Clustering de Failover do Windows estiver em uso, o Nível Funcional de Clustering deverá ter sido o Windows Server 2016 ou posterior no momento da formatação.

Exemplo

Suponha que temos dois arquivos, X e Y, onde cada arquivo é composto por 3 regiões distintas. Cada região de arquivo é armazenada em uma região distinta do volume. O sistema de arquivos armazena o conhecimento de que cada uma dessas regiões de volume é referenciada em uma região de arquivo:

Um diagrama ilustrando o estado das regiões de volumes antes do processo de clonagem.

Agora, suponha que um aplicativo emita uma operação de clone de bloco do Arquivo X, nas regiões de arquivo A e B, para o Arquivo Y no deslocamento onde E está atualmente. O seguinte estado do sistema de arquivos resultaria:

Um diagrama que ilustra o estado das regiões de volumes após o processo de clonagem.

Os dados nas regiões A e B foram efetivamente duplicados do Arquivo X para o Arquivo Y, alterando os mapeamentos de VCN para LCN dentro do volume ReFS. As extensões de disco que dão suporte às regiões A e B não foram lidas, nem as extensões de disco que dão suporte às regiões antigas E e F foram substituídas durante a operação.

Os arquivos X e Y agora compartilham clusters lógicos no disco. Isso se reflete nas contagens de referência mostradas na tabela. O compartilhamento resulta em menor consumo de capacidade de volume do que se as regiões A e B fossem duplicadas no volume subjacente.

Agora, suponha que o aplicativo substitua a região A no Arquivo X. O ReFS faz uma cópia duplicada de A, que agora chamaremos de G. ReFS e, em seguida, mapeará G para o Arquivo X e aplicará a modificação. Isso garante que o isolamento entre os arquivos seja preservado. As contagens de referência são atualizadas adequadamente:

Um diagrama ilustrando o estado das regiões de volume após a modificação da gravação.

Após a gravação de modificação, a região B ainda é compartilhada no disco. Observe que, se a região A fosse maior que um cluster, somente o cluster modificado teria sido duplicado, e a parte restante continuaria compartilhada.

Comportamento de cópia em gravação

O mecanismo allocate-on-write opera no nível do cluster, o que tem implicações importantes para o desempenho e o consumo de espaço:

  • Gravações menores que o tamanho do cluster: uma gravação de qualquer tamanho em um cluster compartilhado (até mesmo 1 byte) resulta na duplicação de todo o cluster. Com o tamanho padrão do cluster de 4KB, uma gravação de 1KB em uma região compartilhada resulta na cópia de 4KB.
  • Gravações abrangendo vários clusters: se uma gravação abranger vários clusters, somente os clusters modificados serão duplicados. Por exemplo, uma gravação de 8 KB com clusters de 4KB duplica dois clusters (total de 8 KB), enquanto a mesma gravação de 8KB com clusters de 64 KB duplica 1 cluster (total de 64 KB).
  • Grandes gravações sequenciais: para cargas de trabalho que frequentemente modificam grandes regiões contíguas após a clonagem, tamanhos de cluster maiores (64 KB) podem reduzir a sobrecarga minimizando o número de operações de cópia em gravação.

Essa granularidade no nível do cluster se aplica a todas as gravações após a clonagem de blocos, incluindo cenários em que o Windows 11 Moment 5 e posteriores executam automaticamente a clonagem de blocos durante operações de cópia.

DUPLICATE_EXTENTS_DATA

FSCTL_DUPLICATE_EXTENTS_TO_FILE