Clonage de bloc
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, plutôt que de lire et d’écrire les données de fichier sous-jacentes. Cela permet à la copie de se terminer plus rapidement et de générer moins d’E/S dans le stockage sous-jacent. De plus, plusieurs fichiers peuvent désormais partager des clusters logiques après le clone de bloc, ce qui permet d’économiser de la capacité en ne stockant pas plusieurs fois des clusters identiques sur le disque.
Une opération de clonage de bloc n’interrompt pas l’isolation fournie entre les fichiers. Une fois qu’un clone de bloc est terminé, les écritures dans le fichier source n’apparaissent pas dans la destination, ou inversement.
Le clonage de bloc est disponible uniquement sur le type de système de fichiers ReFS à partir de Windows Server 2016. À compter de la mise à jour de Windows 11 Moment 5 (KB5034848) et des versions ultérieures des builds windows client et Windows Server, le clonage de bloc se produit en mode natif dans les opérations de copie Windows prises en charge.
Bloquer le clonage sur ReFS
ReFS sur Windows Server 2016 implémente le clonage de bloc en remappant des clusters logiques (c’est-à-dire des emplacements physiques sur un volume) de la région source à 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 les 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 sont 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 s’étendre au-delà de 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 peut pouvoir continuer en fractionnant l’opération de clonage de bloc 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 avoir le même paramètre De 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 dans une région distincte du volume. Le système de fichiers stocke les connaissances que chacune de ces régions de volume est référencée dans une région de fichier :
Supposons maintenant qu’une application émet une opération de clonage de bloc de File 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 se traduit par :
Les données des régions A et B ont été dupliquées efficacement du fichier X au fichier Y en modifiant les mappages VCN vers LCN au sein du volume ReFS. Les étendues de disque des régions de stockage A et B n’ont pas été lues, ni les étendues de disque qui sauvegardent les anciennes régions E et F remplacées pendant l’opération.
Les fichiers X et Y partagent désormais des clusters logiques sur le disque. Cela est reflété dans les nombres de références indiqués dans le tableau. Le partage entraîne une consommation inférieure de capacité de volume que si les régions A et B ont été dupliquées sur le volume sous-jacent.
À présent, supposons que l’application remplace la région A dans Le fichier X. ReFS effectue une copie en double d’A, que nous allons maintenant appeler G. ReFS puis mappe 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 la modification de l’écriture, 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.