Clonación de bloques
Una operación de clonación de bloques indica al sistema de archivos que copie un intervalo de bytes de archivo en nombre de una aplicación. El archivo de destino puede ser el mismo que, o diferente, del archivo de origen.
Un sistema de archivos administra las asignaciones de clústeres y extensiones, y puede realizar la copia modificando el número de clúster virtual (VCN) a las asignaciones de números de clúster lógico (LCN) como una operación de metadatos de bajo costo, en lugar de leer y escribir los datos del archivo subyacente. Esto permite que la copia se complete más rápido y genere menos E/S en el almacenamiento subyacente. Además, ahora es posible que varios archivos compartan clústeres lógicos después del clon del bloque, lo que ahorra capacidad sin almacenar clústeres idénticos varias veces en el disco.
Una operación de clonación de bloques no interrumpe el aislamiento proporcionado entre archivos. Una vez completado un clon de bloque, las escrituras en el archivo de origen no aparecen en el destino o viceversa.
La clonación de bloques solo está disponible en el tipo de sistema de archivos ReFS a partir de Windows Server 2016. A partir de la actualización de Windows 11 Moment 5 (KB5034848) y versiones posteriores de las compilaciones de cliente de Windows y Windows Server, la clonación de bloques se produce de forma nativa en las operaciones de copia de Windows admitidas.
Bloquear clonación en ReFS
ReFS en Windows Server 2016 implementa la clonación de bloques mediante la reasignación de clústeres lógicos (es decir, ubicaciones físicas en un volumen) desde la región de origen a la región de destino. A continuación, usa un mecanismo de asignación de escritura para garantizar el aislamiento entre esas regiones. Las regiones de origen y destino pueden estar en los mismos archivos, o diferentes.
Esta implementación requiere que los desplazamientos de archivo inicial y final se alineen con los límites del clúster. En ReFS en Windows Server 2016, los clústeres tienen un tamaño de 4 KB de forma predeterminada, pero opcionalmente se pueden establecer en 64 KB. El tamaño del clúster es un parámetro de todo el volumen establecido en tiempo de formato.
Restricciones y comentarios
- Las regiones de origen y destino deben comenzar y terminar en un límite del clúster.
- La región clonada debe ser inferior a 4 GB de longitud.
- La región de destino no debe extenderse más allá del final del archivo. Si la aplicación desea extender la región de destino con datos clonados, se debe llamar en primer lugar a SetEndOfFile.
- Si las regiones de origen y destino están en el mismo archivo, no deben superponerse. (La aplicación puede continuar dividiendo la operación de clonación de bloques en varios clones de bloque que ya no se superponen).
- Los archivos de origen y de destino deben tener el mismo volumen ReFS.
- Los archivos de origen y destino deben tener la misma configuración De secuencias de integridad (es decir, Las secuencias de integridad deben estar habilitadas en ambos archivos o deshabilitarse en ambos archivos).
- Si el archivo de origen es disperso, el archivo de destino también debe serlo.
- La operación de clonación de bloques interrumpirá los bloqueos oportunistas compartidos (también conocidos como bloqueos oportunistas de nivel 2).
- El volumen ReFS debe tener el formato Windows Server 2016 y, si los clústeres de conmutación por error de Windows están en uso, el nivel funcional de agrupación en clústeres debe tener Windows Server 2016 o posterior en tiempo de formato.
Ejemplo
Supongamos que tenemos dos archivos, X e Y, donde cada archivo se compone de 3 regiones distintas. Cada región de archivo se almacena en una región distinta del volumen. El sistema de archivos almacena el conocimiento de que se hace referencia a cada una de esas regiones de volumen en una región de archivo:
Ahora supongamos que una aplicación emite una operación de clonación de bloque de Archivo X, a través de las regiones de archivo A y B, a Archivo Y en el desplazamiento donde E está actualmente. El siguiente estado del sistema de archivos daría como resultado:
Los datos de las regiones A y B se duplicaron eficazmente de Archivo X a Archivo Y modificando las asignaciones de VCN a LCN dentro del volumen ReFS. Las extensiones de disco que respaldan las regiones A y B no se leyeron, ni las extensiones de disco que respaldan las regiones antiguas E y F se sobrescriben durante la operación.
Los archivos X e Y ahora comparten clústeres lógicos en disco. Esto se refleja en los recuentos de referencia que se muestran en la tabla. El uso compartido da como resultado un menor consumo de capacidad de volumen que si las regiones A y B se duplicaron en el volumen subyacente.
Ahora supongamos que la aplicación sobrescribe la región A en el archivo X. ReFS realiza una copia duplicada de A, que ahora llamaremos a G. ReFS asigna G al archivo X y aplica la modificación. Esto asegura que el aislamiento entre los archivos se conserve. Los recuentos de referencia se actualizan correctamente:
Después de modificar la escritura, la región B todavía se comparte en el disco. Ten en cuenta que si la región A fuera mayor que un clúster, solo el clúster modificado se habría duplicado y el resto seguiría siendo compartido.