Clonagem de blocos
Uma operação de clone de bloco de instrui o sistema de ficheiros a copiar um intervalo de bytes do ficheiro a pedido de uma aplicação. O arquivo de destino pode ser igual ou diferente do arquivo de origem.
Um sistema de arquivos gerencia os mapeamentos de Clusters e Extensõese pode executar a cópia alterando os mapeamentos de número de cluster virtual (VCN) para 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 ficheiros agora podem compartilhar clusters lógicos após o clone do bloco, economizando capacidade ao evitar o armazenamento de clusters idênticos várias vezes no disco.
Uma operação de clone de bloco não compromete o isolamento providenciado entre ficheiros. Após a conclusão de um clone de bloco, as escritas no ficheiro de origem não aparecem no destino, ou vice-versa.
A clonagem de bloco está disponível somente no sistema de arquivos ReFS tipo começando com o Windows Server 2016. A partir da atualização do Momento 5 do Windows 11 (KB5034848) e versões posteriores do cliente Windows e do Windows Server, a clonagem de blocos (block cloning) ocorre nativamente em operações de cópia do Windows suportadas.
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 alocação na escrita 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 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 de comprimento.
- A região de destino não deve se estender além do final do arquivo. Se o aplicativo deseja estender o destino com dados clonados, ele deve primeiro chamar SetEndOfFile.
- Se as regiões de origem e de destino estiverem no mesmo arquivo, elas não devem 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 ReFS.
- Os arquivos de origem e de destino devem ter a mesma configuração Integrity Streams (ou seja, Integrity Streams deve estar habilitado em ambos os arquivos ou desabilitado 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á 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 Failover Clustering do Windows estiver em uso, o Nível Funcional de Clustering deve ter sido o Windows Server 2016 ou posterior no momento da formatação.
Exemplo
Suponhamos que temos dois ficheiros, X e Y, onde cada ficheiro é 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. Isto reflete-se nas contagens de referência apresentadas no quadro. A partilha resulta num consumo de capacidade de volume mais baixo do que se as regiões A e B fossem duplicadas no volume subjacente.
Agora, suponha que o aplicativo substitui a região A no Arquivo X. O ReFS faz uma cópia duplicada de A, que agora chamaremos de G. 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 modificação da gravação, a região B ainda permanece partilhada no disco. Observe que, se a região A fosse maior que um cluster, apenas o cluster modificado teria sido duplicado e a parte restante teria permanecido compartilhada.