transferts de données déchargés sous Windows

ODX (Transfert de données déchargé) est une fonctionnalité qui accélère les opérations de copie et de déplacement de serveurs. Cette fonctionnalité est disponible à partir de Windows Server 2012 et est prise en charge sur les volumes NTFS. Cette page décrit ODX d’un point de vue système de fichiers et mini-filtre. Pour obtenir des informations relatives aux périphériques de stockage, veuillez consulter la section Transferts de données déchargés pour Windows Storage.

Le transfert de données entre ordinateurs ou au sein d’un même ordinateur est une activité fréquente des systèmes de fichiers. L’utilisation des fonctions standards ReadFile et WriteFile fonctionne bien du point de vue fonctionnel, mais cela implique un transfert important de données à travers tous les niveaux du système et potentiellement à travers un réseau. Cette complexité peut affecter la disponibilité des systèmes impliqués dans le transfert ainsi que le réseau connectant les systèmes. Les capacités avancées disponibles avec de nombreux sous-systèmes de stockage offrent un moyen plus efficace d’exécuter la tâche de transfert de données.

Les applications peuvent tirer parti de ces capacités pour décharger le processus de transfert de données vers le sous-système de stockage. Les filtres de systèmes de fichiers peuvent généralement surveiller ces actions en interceptant les demandes de lecture et d’écriture sur un volume. Des actions supplémentaires sont nécessaires pour que les filtres prennent conscience des ODX.

Transferts de données typiques

Aujourd’hui, déplacer des données dans un scénario applicatif est plus simple. Cela consiste à lire les données dans la mémoire locale, puis à les écrire à un nouvel emplacement. Le diagramme suivant illustre ce scénario.

Ce scénario implique la copie d’un fichier entre deux emplacements sur deux serveurs de fichiers différents, chacun avec son propre disque virtuel exposé via un Intelligent Storage Array (ISA). Le système initiateur doit d’abord lire les données du disque virtuel source dans un tampon local. Il les emballe ensuite et les transmet via un transport et un protocole (comme SMB sur 1 GbE) au second système. Le second système reçoit alors les données et les sort vers un tampon local. Ensuite, le système cible écrit les données sur le disque virtuel de destination. Ce scénario décrit une méthode de transfert de données classique Read/Write qui est exécutée plusieurs fois par de nombreuses applications différentes chaque jour.

Bien que les lectures et écritures standard fonctionnent bien dans la plupart des scénarios, les données destinées à être copiées pourraient se trouver sur des disques virtuels gérés par le même Intelligent Storage Array. Cela signifie que les données sont déplacées hors de la matrice, vers un serveur, à travers un transport réseau, vers un autre serveur, et de nouveau dans la même matrice. Le fait de déplacer des données au sein d’un serveur et à travers un transport réseau peut affecter considérablement la disponibilité de ces systèmes. En outre, le débit du déplacement des données est limité par le débit et la disponibilité du réseau.

Transferts de données déchargés (ODX)

Décharger le transfert de données

Deux FSCTL ont été introduits dans Windows 8 pour faciliter une méthode de déchargement du transfert de données. Ce déchargement déplace la charge du transfert des bits des serveurs vers un transfert de bits qui se produit intelligemment au sein des sous-systèmes de stockage. La meilleure façon de visualiser la sémantique de la commande est de les considérer comme analogues à une lecture non mise en mémoire tampon et une écriture non mise en mémoire tampon.

• FSCTL_OFFLOAD_READ

  Cette demande de contrôle prend un décalage dans le fichier à lire et une longueur souhaitée dans la structure FSCTL_OFFLOAD_READ_INPUT. Si pris en charge, le sous-système de stockage hébergeant le fichier reçoit la commande de lecture déchargée associée. Il génère ensuite un jeton, qui est une représentation logique des données à lire au moment de la commande de lecture déchargée. Cette chaîne de jeton est renvoyée à l’appelant dans la structure FSCTL_OFFLOAD_READ_OUTPUT.

• FSCTL_OFFLOAD_WRITE

  Cette demande de contrôle prend un décalage dans le fichier à écrire, la longueur souhaitée de l’écriture et le jeton qui est une représentation logique des données à écrire. Si pris en charge, le sous-système de stockage hébergeant le fichier à écrire reçoit la commande d’écriture déchargée associée. Il tente d’abord de reconnaître le jeton donné, puis effectue l’opération d’écriture si possible. L’opération d’écriture est effectuée sous Windows, et donc les composants du système de fichiers et les piles de stockage ne voient pas le transfert de données. Une fois le transfert de données terminé, le nombre d’octets écrits est renvoyé à l’appelant.

Similaire au premier diagramme, le diagramme suivant montre une simple copie de fichier entre deux disques virtuels sur deux serveurs différents.

Cependant, au lieu de faire des lectures et écritures normales, nous déchargeons la charge lourde du transfert de bits vers la matrice de stockage. Le premier système émet l’opération de lecture déchargée, demandant à la matrice de générer un jeton représentant une vue à un instant donné des données à lire dans la région du premier disque virtuel. Le premier système transmet ensuite le jeton au second système, qui à son tour émet une opération d’écriture déchargée sur le second disque virtuel avec le jeton. La matrice interprète alors le jeton et tente d’effectuer le transfert de données entre les disques virtuels. Le transfert de données réel se produit au sein de la matrice de stockage intelligente, et non entre les deux hôtes. Ce design améliore considérablement la disponibilité des deux systèmes tout en éliminant virtuellement le trafic réseau entre les systèmes.

Intégration avec le moteur de copie

Le moteur de copie principal dans Windows est utilisé par CopyFile et les fonctions associées. À partir de Windows 8, le moteur de copie tente de manière transparente d’utiliser ODX avant le chemin de code de copie de fichier traditionnel. Les API de copie sont utilisées par la plupart des applications, des utilitaires et du shell. Ces appelants peuvent utiliser les capacités d’ODX par défaut avec peu, voire aucune, modification du code ou intervention de l’utilisateur.

Les étapes suivantes résument la manière dont le moteur de copie tente un ODX :

1. Le moteur de copie émet un FSCTL_OFFLOAD_READ sur le fichier source pour obtenir un jeton de lecture.
2. S’il y a eu un échec lors de la récupération du jeton de lecture, le moteur de copie revient à des lectures et écritures traditionnelles (le chemin de code de copie de fichier traditionnel). Si l’échec indique que le volume source ne prend pas en charge le déchargement, le moteur de copie marque également le volume dans un cache par processus. Le moteur de copie n’essaie plus de décharger pour les volumes dans le cache par processus.
3. Si le jeton a été récupéré avec succès, le moteur de copie tente d’émettre des commandes FSCTL_OFFLOAD_WRITE sur le fichier cible par grands segments jusqu’à ce que toutes les données représentées logiquement par le jeton soient écrites en déchargement.
4. Toute erreur lors de l’exécution de la lecture/écriture en déchargement entraîne la reprise par le moteur de copie du chemin de code de lecture/écriture traditionnel. Cette reprise commence là où le chemin de code de déchargement s’est terminé (là où la lecture ou l’écriture a été tronquée). Le moteur de copie met à jour le même cache par processus pour qu’il n’essaie pas de déchargement sur ces volumes si l’une des conditions suivantes est remplie. Ce cache par processus est réinitialisé périodiquement.

• L’échec indique que le volume de destination ne prend pas en charge le déchargement.
• Le volume source ne peut pas atteindre le volume de destination.

Les fonctions suivantes prennent en charge les ODX :

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

Les fonctions suivantes ne prennent pas en charge les ODX :

• CopyFileTransacted
• MoveFileTransacted

Scénarios pris en charge de transfert de données déchargé

Le support des opérations de déchargement est fourni dans la pile de stockage Hyper-V et dans le serveur de fichiers Windows SMB. Lorsque le stockage physique sous-jacent prend en charge les opérations ODX, les appelants peuvent émettre des commandes FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE sur des fichiers se trouvant sur des VHD ou sur des partages de fichiers distants, que ce soit à partir d’une machine virtuelle ou sur du matériel physique. Le diagramme suivant illustre les cibles source et destination les plus basiques prises en charge pour les ODX.

Modèle d’adhésion des filtres de systèmes de fichiers et effet sur les applications

À partir de Windows 8, Filter Manager permet à un filtre de spécifier la capacité de déchargement comme une fonctionnalité prise en charge. Les filtres de systèmes de fichiers attachés à un volume peuvent collectivement déterminer si une certaine opération déchargée est prise en charge. Si ce n’est pas pris en charge, l’opération échoue avec un code d’erreur approprié.

Un filtre doit indiquer qu’il prend en charge FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE via une valeur DWORD de registre nommée SupportedFeatures, située dans la définition du service de pilote dans le registre à HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\nom du filtre de pilote\. Cette valeur contient des champs de bits où les bits déterminent quelle fonctionnalité est activée, et doit être définie lors de l’installation du filtre.

Les bits actuellement définis sont :

Le modèle d’adhésion du filtre peut être activé ou désactivé en fonction de la valeur présente dans la clé de registre HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode, qui a les valeurs suivantes :

Test

Pour vérifier les fonctionnalités prises en charge d’un filtre dans la pile, utilisez l’utilitaire fltmc. Exécutez fltmc instances –v [volume]: en tant qu’utilisateur élevé, et vérifiez la colonne SprtFtrs :

• Si la valeur SprtFtrs est 0x00, cela implique que le filtre bloque le déchargement sur ce volume. Si SprtFtrs est défini sur 0x03, les deux opérations de déchargement sont prises en charge.

Vérification de la prise en charge des fonctionnalités dans le traitement IRP

Dans le cadre du traitement IRP, la routine FsRtlGetSupportedFeatures récupère l’état agrégé SupportedFeatures pour tous les filtres attachés à la pile de volume donnée. Les composants tels que le gestionnaire d’E/S et SRV (SMB) appellent cette routine pour valider l’état SupportedFeatures pour tous les filtres sur la pile. Les composants qui créent leurs propres IRP de déchargement doivent appeler cette fonction pour valider la prise en charge de l’adhésion pour cette opération.

Considérations pour les pilotes de filtre

ODX est un moyen de déplacer des données dans le centre de données. En raison de l’intégration de la logique de déchargement dans le moteur de copie principal, de nombreuses applications ont par défaut la capacité d’effectuer un transfert de données déchargé sans adhésion explicite. Par conséquent, les développeurs de filtres doivent comprendre comment ces opérations affectent les filtres. Ne pas comprendre pleinement ces opérations ou ne pas évaluer le changement dans le flux de données peut potentiellement entraîner des scénarios où les données peuvent devenir incohérentes ou corrompues. La liste suivante résume un ensemble d’éléments d’action pour les développeurs de filtres à prendre en compte avec le déchargement :

• Comprenez ce flux de données, l’effet sur le filtre, et la capacité du filtre à prendre en charge ces opérations déchargées.
• Mettez à jour votre programme d’installation de filtre pour ajouter une valeur REG_DWORD pour SupportedFeatures à la sous-clé HKLM\System\CurrentControlSet\Services\[filtre]. Initialisez-la pour spécifier la fonctionnalité de déchargement.
• Pour les filtres qui souhaitent agir sur les opérations de déchargement, mettez à jour l’enregistrement pour IRP_MJ_FILE_SYSTEM_CONTROL pour gérer FSCTL_OFFLOAD_READ et FSCTL_OFFLOAD_WRITE.
• Pour les filtres qui doivent bloquer les opérations déchargées, renvoyez le code de statut STATUS_NOT_SUPPORTED depuis le filtre. Ne vous fiez pas à la valeur du registre pour imposer le blocage des opérations déchargées car les utilisateurs finaux peuvent la modifier. Un filtre doit explicitement autoriser ou interdire les opérations de déchargement.

Jetons de copie

Avec les opérations déchargées, la pile d’E/S ne voit pas les données du fichier. À la place, les données du fichier sont vues comme un jeton de 512 octets qui est le proxy logique des données. Ce jeton est soit :

• Une chaîne opaque et unique d’un format spécifique au fournisseur générée par le sous-système de stockage.
• Un type bien connu pour représenter un modèle de données (comme une plage de données qui est logiquement équivalente à zéro).

Les modifications apportées aux données du jeton proxy entraînent l’invalidation du jeton ou la persistance des données originales par le sous-système de stockage par des moyens spécifiques au fournisseur, tels qu’un mécanisme de capture instantanée. Les demandes de lecture déchargées ultérieures pour une plage spécifiée dans un fichier entraînent des jetons uniques.

Il existe des classes de jetons qui représentent un modèle de données bien défini. Le jeton bien connu le plus courant est le jeton zéro, qui est équivalent à zéro. Lorsqu’un jeton est défini comme un jeton bien connu, le membre TokenType dans la structure STORAGE_OFFLOAD_TOKEN est défini sur STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN. Lorsque ce champ est défini, le membre WellKnownPattern détermine quel modèle de données est représenté par le jeton.

• Lorsque le champ WellKnownPattern est défini sur STORAGE_OFFLOAD_PATTERN_ZERO ou STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION, cela indique le jeton zéro. Lorsque ce jeton est renvoyé par une opération FSCTL_OFFLOAD_READ, cela indique que les données contenues dans la plage de fichier souhaitée sont logiquement équivalentes à zéro. Lorsque ce jeton est fourni à une opération FSCTL_OFFLOAD_WRITE, cela indique que la plage souhaitée du fichier à écrire doit être logiquement mise à zéro.
• Autre que le jeton zéro, aucun autre modèle de jeton bien connu n’est actuellement défini. Il n’est pas recommandé aux utilisateurs de définir leurs propres modèles de jetons bien connus.

Troncation

Le sous-système de stockage sous-jacent avec lequel Windows communique peut traiter moins de données que celles souhaitées dans une opération de déchargement. Cette condition est appelée troncature. Avec une lecture déchargée, le jeton renvoyé représente une plage de données inférieure aux données demandées. Le membre TransferLength dans la structure FSCTL_OFFLOAD_READ_OUTPUT est utilisé pour indiquer cette valeur, qui est un nombre d’octets à partir du début de la plage du fichier à lire. Pour une écriture déchargée, une troncature indique que moins de données ont été écrites que ce qui était souhaité. Le membre LengthWritten dans la structure FSCTL_OFFLOAD_WRITE_OUTPUT indique cette valeur, qui est un nombre d’octets à partir du début de la plage du fichier à écrire. Les erreurs dans le traitement des commandes, ou les limitations dans la pile pour des plages importantes, entraînent une troncature.

Il existe deux scénarios dans lesquels NTFS tronque la plage à lire ou écrire en déchargement :

1. La plage de copie est tronquée à la longueur des données valides (VDL) si VDL est avant la fin du fichier (EOF). Cette action suppose que VDL est alignée à une limite de secteur logique, sinon voir le scénario.

   

   Lors d’une opération FSCTL_OFFLOAD_READ, l’indicateur OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE est défini dans la structure FSCTL_OFFLOAD_READ_OUTPUT indiquant que le reste du fichier contient des zéros, et le membre TransferLength est tronqué à VDL.

2. Similaire au scénario 1, mais lorsque VDL n’est pas alignée sur une limite de secteur logique, NTFS tronque la plage souhaitée à la limite de secteur logique suivante.

   

Limites

• Les opérations de déchargement ne sont prises en charge que sur les volumes NTFS.
• Les opérations de déchargement sont prises en charge via des serveurs de fichiers distants si les deux conditions suivantes sont remplies :
  • Le partage distant est un volume NTFS.
  • Le serveur exécute Windows Server 2012 ou une version ultérieure (à condition que la pile distante prenne également en charge les opérations de déchargement).
• NTFS ne prend pas en charge les FSCTL de déchargement effectués sur des fichiers chiffrés avec Bitlocker ou le chiffrement NTFS (EFS), les fichiers dédupliqués, les fichiers compressés, les fichiers résidents, les fichiers clairsemés, ou les fichiers participant à des transactions TxF.
• NTFS ne prend pas en charge les FSCTL de déchargement effectués sur des fichiers dans une capture instantanée volsnap.
• NTFS échoue les FSCTL de déchargement si l’une des conditions suivantes est remplie. Cette approche suit les mêmes sémantiques que les E/S non mises en cache.
  • La plage de fichier souhaitée n’est pas alignée sur la taille de secteur logique du périphérique source.
  • La plage de fichier souhaitée n’est pas alignée sur la taille de secteur logique du périphérique de destination.
• Le fichier de destination doit être préalloué (SetEndOfFile et non SetAllocation) avant FSCTL_OFFLOAD_WRITE.
• Lorsque NTFS traite des lectures et écritures en déchargement, il appelle d’abord CcCoherencyFlushAndPurgeCache pour valider les données modifiées dans le cache du système. Cette action a la même sémantique que les E/S non mises en cache.