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
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 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 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 no momento do 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 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 do Integrity Streams (ou seja, o Integrity Streams deve ser ativado em ambos os arquivos ou desativado 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 Windows Server 2016 e, se o Clustering de Failover do Windows estiver em uso, o Nível Funcional de Clustering deverá ter sido Windows Server 2016 ou posterior no momento do formato.
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. O ReFS mapeia G no 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.