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 el archivo de origen, o diferente de él.

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 de archivo subyacentes. Esto permite que la copia se complete más rápido y genere menos E/S en el almacenamiento subyacente. Además, varios archivos ahora pueden compartir clústeres lógicos después del clon de bloque, lo que ahorra capacidad al no almacenar clústeres idénticos varias veces en el disco.

Una operación de clonación de bloques no interrumpe el aislamiento proporcionado entre los 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.

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 en 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 el destino con datos clonados, primero debe llamar 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á bloqueos oportunistas compartidos (también conocidos como bloqueos oportunistas de nivel 2).
• El volumen ReFS debe haberse formateado con Windows Server 2016 y, si la agrupación en clústeres de conmutación por error de Windows está en uso, el nivel funcional de agrupación en clústeres debe haberse Windows Server 2016 o posterior en el momento del 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 bloques desde el archivo X, a través de las regiones de archivo A y B, al 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 el disco. Esto se refleja en los recuentos de referencia que se muestran en la tabla. El uso compartido da como resultado un consumo de capacidad de volumen menor 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.

Temas relacionados

DUPLICATE_EXTENTS_DATA

FSCTL_DUPLICATE_EXTENTS_TO_FILE