Clonage de bloc sur ReFS

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Le clonage de bloc demande au système de fichiers de copier une plage d’octets de ficher pour le compte d’une application. Les fichiers source et de destination utilisés peuvent être identiques ou différents. Toutefois, ces opérations de copie sont coûteuses, car elles déclenchent des lectures et des écritures coûteuses sur les données physiques sous-jacentes.

Dans ReFS, le clonage de bloc effectue les copies dans le cadre d’une opération de métadonnées moins coûteuse que la lecture et l’écriture des données de fichier. ReFS permet à un ensemble de fichiers de partager les mêmes clusters logiques (emplacements physiques sur un volume). Les opérations de copie ont donc uniquement à remapper une région d’un fichier vers un emplacement physique distinct, ce qui est plus rapide et logique que d’effectuer des opérations physiques coûteuses. Ce processus accélère les opérations de copie et réduit le nombre d’E/S générées dans le stockage sous-jacent. Cette amélioration profite également aux charges de travail virtualisées, car elle accélère considérablement les opérations de fusion des points de contrôle .vhdx dans le cadre d’opérations de clonage de bloc. De plus, comme plusieurs fichiers peuvent partager les mêmes clusters logiques, les données identiques ne sont pas stockées à plusieurs emplacements physiques, ce qui augmente la capacité de stockage.

Fonctionnement

Le clonage de bloc sur ReFS transforme les opérations de données de fichier en opérations de métadonnées. Pour rendre possible cette optimisation, ReFS introduit des nombres de références dans ses métadonnées pour les régions copiées. Ce nombre de références indique le nombre de régions du fichier distinctes qui font référence aux mêmes régions physiques. Cela permet à plusieurs fichiers de partager les mêmes données physiques :

Show reference count updates when multiple files reference same region

ReFS enregistre le nombre de références pour chaque cluster logique, ce qui maintient l’isolation entre les fichiers : les opérations d’écriture dans les régions partagées déclenchent un mécanisme d’allocation sur écriture, où ReFS alloue une nouvelle région pour l’opération d’écriture entrante. Ce mécanisme préserve l’intégrité des clusters logiques partagés.

Exemple

Prenons l’exemple de deux fichiers, appelés X et Y, qui contiennent chacun trois régions mappées à des clusters logiques distincts.

Two files each with three distinct regions which all map to regions that have ref count 1

Supposons maintenant qu’une application émette une opération de clonage de bloc du fichier X vers le fichier Y pour que les régions A et B soient copiées au niveau de la région E. Nous obtenons alors l’état du système de fichiers suivant :

Reference count shows 2 for blocked clone region

Cet état du système de fichiers indique que la région de clonage de bloc a été dupliquée. ReFS effectue cette opération de copie uniquement en mettant à jour les mappages VCN en LCN, sans que cela nécessite de lecture de données physiques, ni de remplacement de données physiques dans le fichier Y. Les fichiers X et Y partagent maintenant des clusters logiques, comme le montre les nombres de références dans le tableau. Du fait qu’il n’y a pas de données physiques à copier, ReFS permet d’utiliser moins de capacité de stockage sur le volume.

Supposons maintenant que l’application tente de remplacer la région A dans le fichier X. ReFS va dupliquer la région partagée, mettre à jour les nombres de références en conséquence et effectuer l’opération de copie entrante dans la nouvelle région dupliquée. Cela permet de préserver l’isolation entre les fichiers.

Isolation preserved by writing to a new region G and updating ref counts

Après cette modification, la région B est toujours partagée par les deux fichiers. 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.

Remarques et restrictions relatives à la fonctionnalité

  • Les régions source et de destination doivent commencer et finir à la limite d’un cluster.
  • La taille de la région clonée doit être inférieure à 4 Go.
  • Le nombre maximal de régions de fichier qui peuvent être mappées à la même région physique est de 8175.
  • La région de destination ne doit pas dépasser la fin du fichier. Pour que l’application puisse étendre la destination 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 doit pouvoir continuer l’opération de clonage de bloc en la fractionnant en plusieurs clones de bloc 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 être définis avec le même paramètre Flux d’intégrité.
  • Si le fichier source est partiellement alloué, le fichier de destination doit l’être également.
  • L’opération de clonage de bloc supprime les verrous opportunistes partagés (également appelés verrous opportunistes de niveau 2).
  • Le volume ReFS doit avoir été formaté avec Windows Server 2016 et, si le clustering de basculement est utilisé, le niveau fonctionnel du clustering doit avoir été défini sur Windows Server 2016 ou une version ultérieure au moment du formatage.

Références supplémentaires