Clonage de blocs

Une opération de clonage de bloc indique au système de fichiers de copier une plage d’octets de fichier pour le compte d’une application. Le fichier de destination peut être identique ou différent du fichier source.

Un système de fichiers gère les mappages de clusters et d’étendues, et peut être en mesure d’effectuer la copie en modifiant le numéro de cluster virtuel (VCN) en mappages de numéro de cluster logique (LCN) en tant qu’opération de métadonnées à faible coût, au lieu de lire et d’écrire les données de fichier sous-jacentes. Cela permet à la copie de se terminer plus rapidement et génère moins d’E/S dans le stockage sous-jacent. En outre, plusieurs fichiers peuvent désormais partager des clusters logiques après le clonage de bloc, ce qui permet d’économiser de la capacité en ne stockant pas les clusters identiques plusieurs fois sur le disque.

Une opération de clonage de bloc n’interrompt pas l’isolation fournie entre les fichiers. Une fois le clone de bloc terminé, les écritures dans le fichier source n’apparaissent pas dans la destination, ou vice versa.

Le clonage de blocs est disponible uniquement sur le type de système de fichiers ReFS commençant par Windows Server 2016.

Clonage de bloc sur ReFS

ReFS sur Windows Server 2016 implémente le clonage de blocs en remappage des clusters logiques (c’est-à-dire des emplacements physiques sur un volume) de la région source vers la région de destination. Il utilise ensuite un mécanisme d’allocation en écriture pour garantir l’isolation entre ces régions. Les régions source et de destination peuvent se trouver dans des fichiers identiques ou différents.

Cette implémentation nécessite que les décalages de fichier de début et de fin soient alignés sur les limites du cluster. Dans ReFS sur Windows Server 2016, les clusters ont une taille de 4 Ko par défaut, mais peuvent éventuellement être définis sur 64 Ko. La taille du cluster est un paramètre à l’échelle du volume défini au moment du format.

Restrictions et remarques

• Les régions source et de destination doivent commencer et se terminer à une limite de cluster.
• La taille de la région clonée doit être inférieure à 4 Go.
• La région de destination ne doit pas dépasser la fin du fichier. Si l’application souhaite étendre la destination avec des données clonées, elle doit d’abord appeler SetEndOfFile.
• Si les régions source et de destination se trouvent dans le même fichier, elles ne doivent pas se chevaucher. (L’application peut être en mesure de continuer en divisant l’opération de clonage de bloc en plusieurs clones de blocs qui ne se chevauchent plus.)
• Les fichiers source et de destination doivent se trouver sur le même volume ReFS.
• Les fichiers source et de destination doivent avoir le même paramètre Flux d’intégrité (autrement dit, les flux d’intégrité doivent être activés dans les deux fichiers ou désactivés dans les deux fichiers).
• Si le fichier source est partiellement alloué, le fichier de destination doit l’être également.
• L’opération de clonage de bloc interrompt les verrous opportunistes partagés (également appelés verrous opportunistes de niveau 2).
• Le volume ReFS doit avoir été mis en forme avec Windows Server 2016, et si le clustering de basculement Windows est en cours d’utilisation, le niveau fonctionnel de clustering doit avoir été Windows Server 2016 ou version ultérieure au moment du format.

Exemple

Supposons que nous avons deux fichiers, X et Y, où chaque fichier est composé de 3 régions distinctes. Chaque région de fichier est stockée sur une région distincte du volume. Le système de fichiers stocke la connaissance que chacune de ces régions de volume est référencée dans une région de fichiers :

Supposons maintenant qu’une application émet une opération de clonage de bloc du fichier X, sur les régions de fichiers A et B, vers le fichier Y au décalage où E est actuellement. L’état du système de fichiers suivant en résulterait :

Les données des régions A et B ont été effectivement dupliquées du fichier X au fichier Y en modifiant les mappages VCN à LCN dans le volume ReFS. Les extensions de disque de sauvegarde des régions A et B n’ont pas été lues, ni les extensions de disque qui sauvegardent les anciennes régions E et F ont été remplacées pendant l’opération.

Les fichiers X et Y partagent désormais des clusters logiques sur le disque. Cela se reflète dans les nombres de références indiqués dans le tableau. Le partage entraîne une consommation de capacité de volume plus faible que si les régions A et B étaient dupliquées sur le volume sous-jacent.

Supposons maintenant que l’application remplace la région A dans le fichier X. ReFS effectue une copie en double de A, que nous allons maintenant appeler G. ReFS mappe ensuite G dans le fichier X et applique la modification. Cela permet de préserver l’isolation entre les fichiers. Les nombres de références sont mis à jour de manière appropriée :

Après l’écriture de modification, la région B est toujours partagée sur le disque. Notez que si la région A avait été plus grande qu’un cluster, seul le cluster modifié aurait été dupliqué, et la partie restante aurait continué à être partagée.

Rubriques connexes

DUPLICATE_EXTENTS_DATA

FSCTL_DUPLICATE_EXTENTS_TO_FILE