Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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:
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:
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:
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.