Clonagem em bloco
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 de arquivo subjacentes. 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 de bloco, economizando capacidade por 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 arquivos. Depois que um clone de bloco é concluído, as gravações no arquivo de origem não aparecem no destino ou vice-versa.
A clonagem em bloco está disponível somente no tipo de sistema de arquivos ReFS que começa com o Windows Server 2016. A partir da atualização do Windows 11 Moment 5 (KB5034848) e versões posteriores do cliente Windows e compilações do Windows Server, a clonagem de blocos ocorre nativamente em operações de cópia do Windows com suporte.
Bloquear clonagem no ReFS
O ReFS no Windows Server 2016 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 alocar na gravação para garantir o isolamento entre essas regiões. As regiões de origem e de destino podem estar nos mesmos arquivos ou em arquivos diferentes.
Essa implementação requer que os deslocamentos de arquivo inicial e final sejam alinhados aos limites do cluster. No ReFS no Windows Server 2016, os clusters têm 4 KB de tamanho por padrão, mas podem ser definidos opcionalmente como 64 KB. O tamanho do cluster é um parâmetro de todo o volume definido em tempo de formato.
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á chamar SetEndOfFile primeiro.
- 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 clonagem 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, os 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 clonagem 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 e, se o Clustering de Failover do Windows estiver em uso, o Nível Funcional de Clustering deve ter sido o Windows Server 2016 ou posterior em tempo de formato.
Exemplo
Suponha que tenhamos 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, sobre as 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 VCN para LCN dentro do volume ReFS. As extensões de disco que suportam as regiões A e B não foram lidas, nem as extensões de disco que suportam as 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. O ReFS mapeia G para o Arquivo X e aplica 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.