Mise à jour de la compatibilité des disques au format avancé (4K)

Platforms

Clients Windows XP, Windows Vista, Windows 7, Windows 7 SP1, Windows 8
Serveurs Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Description

Cet article est une version mise à jour de l’article intitulé Mise à jour de la compatibilité des disques à émulation de 512 octets (512e) publié pour Windows 7 SP1 et Windows Server 2008 R2 SP1. Cette mise à jour contient de nombreuses nouvelles informations, dont certaines ne s’appliquent qu’à Windows 8 et Windows Server 2012.

Les densités surfaciques augmentent chaque année, et avec l’avènement récent des disques de 3 To, les mécanismes de correction d’erreur utilisés pour gérer le rapport signal/bruit (SNR) décroissant deviennent inefficaces en termes d’espace ; c’est-à-dire qu’une quantité accrue de surcharge est nécessaire pour garantir que le support est utilisable. L’une des solutions de l’industrie du stockage pour améliorer ce mécanisme de correction d’erreur est d’introduire un format de support physique différent incluant une taille de secteur physique plus grande. Ce nouveau format de support physique est appelé Format Avancé. Il n’est donc plus sûr de faire des suppositions concernant la taille des secteurs des dispositifs de stockage modernes, et les développeurs devront étudier les suppositions sous-jacentes à leur code pour déterminer s’il y a un impact.

Cette rubrique présente l’effet des dispositifs de stockage au Format Avancé sur les logiciels, discute des mesures que les applications peuvent prendre pour aider à prendre en charge ce type de support, et aborde l’infrastructure que Microsoft a introduite avec Windows Vista, Windows 7 et Windows 8 pour permettre aux développeurs de prendre en charge ces types de dispositifs. Bien que le matériel présenté dans cette rubrique fournisse des lignes directrices pour améliorer la compatibilité avec les disques au Format Avancé, les informations s’appliquent généralement à tous les systèmes avec des disques au Format Avancé fonctionnant sous Windows Vista, Windows 7 et Windows 8.

Résumé des nouvelles fonctionnalités liées aux grands secteurs

La liste ci-dessous résume les nouvelles fonctionnalités livrées dans le cadre de Windows 8 et Windows Server 2012 pour aider à améliorer l’expérience des clients et des développeurs avec les disques à grands secteurs. Une description plus détaillée de chaque élément suit.

• S’appuie sur la prise en charge de Windows 7 SP1 pour les disques 4K avec émulation (512e), et fournit une prise en charge complète intégrée pour les disques avec une taille de secteur de 4K sans émulation (4K Native). Certaines applications et scénarios pris en charge incluent :
  • Capacité d’installer Windows et de démarrer à partir d’un disque de secteur 4K sans émulation (Disque 4K Native)
  • Format de fichier VHD et nouveau format de fichier VHDX
  • Prise en charge complète d’HyperV
  • Sauvegarde Windows
  • Prise en charge complète dans le système de fichiers NT (NTFS)
  • Prise en charge complète avec les nouveaux Espaces de stockage et Pools (SSP)
  • Prise en charge complète avec Windows Defender
• Fournit une nouvelle API pour interroger la taille du secteur physique (FileFsSectorSizeInformation) :
  • Disponible pour les volumes réseau
  • Peut être émise pour tout handle de fichier
  • Disponible pour les applications non privilégiées
  • Modèle d’utilisation plus convivial
• Inclut un utilitaire en ligne de commande fsutil amélioré pour interroger la taille des secteurs logique et physique du volume avec les informations d’alignement (version de base de l’utilitaire sans informations d’alignement disponible pour Windows 7 avec Microsoft KB 982018 et Windows Server 2008 R2 avec Microsoft KB 982018)

Introduction aux disques au format avancé (4K)

L’un des problèmes de l’introduction de ce changement dans le format des supports est le potentiel d’introduire des problèmes de compatibilité avec les logiciels et matériels existants. Comme solution de compatibilité temporaire, l’industrie du stockage introduit initialement des disques qui émulent un disque à secteur de 512 octets, mais rendent disponibles des informations sur la véritable taille des secteurs par le biais des commandes ATA et SCSI standard. En conséquence de cette émulation, il existe essentiellement deux tailles de secteur :

Secteur logique : l’unité utilisée pour le adressage de blocs logiques du support. On peut également la considérer comme la plus petite unité d’écriture que le stockage peut accepter. C’est l’émulation.
Secteur physique : l’unité pour laquelle les opérations de lecture et d’écriture sur le dispositif sont effectuées en une seule opération. C’est l’unité d’écriture atomique.
La plupart des API Windows actuelles, telles que IOCTL_DISK_GET_DRIVE_GEOMETRY, renverront la taille du secteur logique, mais la taille du secteur physique peut être récupérée via le code de contrôle IOCTL_STORAGE_QUERY_PROPERTY, avec les informations pertinentes contenues dans le champ BytesPerPhysicalSector de la structure STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR. Cela est discuté plus en détail plus loin dans l’article.

Types initiaux de supports à grands secteurs

L’industrie du stockage accélère rapidement ses efforts pour passer à ce nouveau type de stockage au Format Avancé pour les supports ayant une taille de secteur physique de 4 Ko. Deux types de supports seront commercialisés :

4 Ko natif : Ce support n’a pas de couche d’émulation et expose directement 4 Ko comme taille de secteur logique et physique. Le problème général avec ce nouveau type de support est que la majorité des applications et systèmes d’exploitation ne recherchent pas et n’alignent pas les E/S sur la taille des secteurs physiques, ce qui peut entraîner des échecs d’E/S inattendus.
Émulation de 512 octets (512e) : ce support a une couche d’émulation comme discuté dans la section précédente et expose 512 octets comme taille de secteur logique (similaire à un disque régulier aujourd’hui), mais rend disponible les informations sur sa taille de secteur physique (4 Ko). Le problème général avec ce nouveau type de média est que la majorité des applications et des systèmes d’exploitation ne comprennent pas l’existence de la taille du secteur physique, ce qui peut entraîner un certain nombre de problèmes comme nous le verrons ci-dessous.
Soutien général de Windows pour les médias à grands secteurs

Ce tableau documente la politique officielle de support de Microsoft pour divers médias et leurs tailles de secteur rapportées. Veuillez consulter cet article KB pour plus de détails.

Noms communs	Taille du secteur logique rapportée	Taille du secteur physique rapportée	Version de Windows avec support
512 octets natifs, 512n	512 octets	512 octets	Toutes les versions de Windows
Format avancé, 512e, AF, émulation 512 octets	512 octets	4 Ko	Windows Vista avec MS KB 2553708 Windows Server 2008* avec MS KB 2553708 Windows 7 avec MS KB 982018 Windows Server 2008 R2* avec MS KB 982018 Toutes les versions de Windows à partir de Windows 7 SP1 et suivantes. Toutes les versions Server à partir de Server 2008 R2 SP1 et suivantes. *À l’exception de Hyper-V. Veuillez consulter la section « Exigences de support applicatif pour les disques à grands secteurs ».
Format avancé, AF, 4K natif, 4Kn	4 Ko	4 Ko	Toutes les versions de Windows à partir de Windows 8 et suivantes Toutes les versions Server à partir de Windows Server 2012 et suivantes
Other	Ni 4 KB ni 512 octets	Ni 4 KB ni 512 octets	Non pris en charge

Remarque

Bien que non souligné dans le tableau précédent, Windows XP, Windows Server 2003 et Windows Server 2003 R2 ne supportent pas les médias 512e ou 4Kn. Bien que le système puisse démarrer et fonctionner de manière minimale, il peut y avoir des scénarios inconnus de problèmes de fonctionnalité, de perte de données ou de performances sous-optimales. Ainsi, Microsoft déconseille fortement l’utilisation de médias 512e avec Windows XP ou d’autres produits basés sur le code de Windows XP (tels que Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64-bit Edition, Windows XP Embedded, Windows Small Business Server 2003 et Windows Small Business Server 2003 R2).

Comment fonctionne l’émulation : lecture-modification-écriture (RMW)

Un support de stockage a une certaine unité au sein de laquelle le support physique peut être modifié. C’est-à-dire que le support ne peut être écrit ou réécrit qu’en unités de la taille du secteur physique. Ainsi, les écritures qui ne sont pas effectuées à ce niveau d’unité nécessiteraient des étapes supplémentaires, que nous allons détailler dans l’exemple ci-dessous.

Dans ce scénario, une application doit mettre à jour le contenu d’un enregistrement Datastor situé dans un secteur logique de 512 octets. Ce diagramme illustre les étapes nécessaires pour que le périphérique de stockage complète l’écriture :

Comme illustré ci-dessus, ce processus implique un certain travail de la part du périphérique de stockage, ce qui peut entraîner une perte de performance. Pour éviter ce travail supplémentaire, les applications doivent être mises à jour pour :

• Interroger la taille du secteur physique
• S’assurer que les écritures sont alignées sur cette taille de secteur physique signalée

Bien que cela puisse initialement sembler n’être qu’un problème de performance, il peut y avoir un problème plus sérieux. Discutons-en dans la section suivante.

Résilience : le coût caché de la lecture-modification-écriture

La résilience parle de la capacité d’une application à récupérer son état entre les sessions. Nous avons vu ce qui est nécessaire pour qu’un dispositif de stockage 512e effectue une écriture de secteur de 512 octets – le cycle Lecture-Modification-Écriture. Voyons ce qui se passerait si le processus de réécriture du secteur physique précédent sur le support était interrompu. Quelles en seraient les conséquences ?

• Étant donné que la plupart des disques durs mettent à jour sur place, le secteur physique, c’est-à-dire la portion du support où le secteur physique était situé, pourrait avoir été corrompu avec des informations incomplètes en raison d’une réécriture partielle. En d’autres termes, vous pouvez considérer qu’il est potentiellement perdu tous les 8 secteurs logiques (que le secteur physique contient logiquement).
• Bien que la plupart des applications avec un magasin de données soient conçues avec la capacité de récupérer des erreurs du support, la perte de huit secteurs, ou en d’autres termes, la perte de huit enregistrements de validation, peut potentiellement rendre impossible la récupération gracieuse du magasin de données. Un administrateur peut avoir besoin de restaurer manuellement la base de données à partir d’une sauvegarde ou même de procéder à une reconstruction longue.
• Un autre impact important est que l’action d’une autre application causant un cycle de lecture-modification-écriture peut potentiellement entraîner la perte de vos données même si votre application n’est pas en cours d’exécution ! Cela est simplement dû au fait que vos données et celles de l’autre application pourraient être situées dans le même secteur physique.

Avec cela en tête, il est important que les logiciels d’application réévaluent toute hypothèse prise dans le code, et soient conscients de la distinction entre la taille des secteurs logiques et physiques, ainsi que de certains scénarios clients intéressants discutés plus loin dans cet article.

Faire la bonne chose (éviter la lecture-modification-écriture)

Bien que certains fournisseurs de stockage puissent introduire des niveaux de mitigation dans certains appareils de stockage 512e pour tenter d’atténuer les problèmes de performance et de résilience du cycle de lecture-modification-écriture, il n’y a qu’un certain nombre de choses que toute mitigation peut gérer en termes de charge de travail. En tant que tel, les applications ne devraient pas se fier à cette mitigation comme solution à long terme. De plus, il n’y a aucune garantie que toutes les classes de disques auront cette mitigation en place, ni qu’elle soit bien conçue.

La solution à cela n’est pas la mitigation dans le disque, mais de concevoir des applications pour faire le bon ensemble de choses pour aider à supporter ce type de média. Cette section discute des scénarios courants où les applications peuvent avoir des problèmes avec des disques à grands secteurs, et suggère une piste d’investigation pour tenter de résoudre chaque problème.

Problème 1 : la partition n’est pas alignée sur une frontière de secteur physique

Lorsque l’administrateur/utilisateur partitionne le disque, la première partition peut ne pas avoir été créée sur une frontière alignée. Cela peut entraîner que toutes les écritures ultérieures ne soient pas alignées sur les frontières des secteurs physiques. Depuis Windows Vista SP1 et Windows Server 2008, la première partition est placée au premier 1024 KB du disque (pour les disques de 4 Go ou plus, sinon l’alignement est de 64 KB) qui est alignée sur une frontière de secteur physique de 4 KB. Cependant, étant donné le partitionnement par défaut dans Windows XP, un utilitaire de partitionnement tiers ou une mauvaise utilisation des API Windows, les partitions créées peuvent ne pas être alignées sur une frontière de secteur physique. Les développeurs devront s’assurer que les API correctes sont utilisées pour aider à garantir l’alignement. Les API recommandées pour aider à garantir l’alignement des partitions sont décrites ci-dessous.

Les API IVdsPack::CreateVolume et IVdsPack2::CreateVolume2 n’utilisent pas le paramètre d’alignement spécifié lors de la création d’un nouveau volume, mais utilisent plutôt la valeur d’alignement par défaut du système d’exploitation (les versions antérieures à Windows Vista SP1 utiliseront 63 octets, et postérieures à Windows Vista SP1 utiliseront les valeurs par défaut indiquées ci-dessus). Au lieu de cela, utilisez les API IVdsCreatePartitionEx::CreatePartitionEx ou IVdsAdvancedDisk::CreatePartition qui utilisent le paramètre d’alignement spécifié pour ces applications qui doivent créer des partitions.

La meilleure façon d’aider à garantir que l’alignement est correct est de le faire correctement lors de la création initiale de la partition. Sinon, votre application devra tenir compte de l’alignement lors des écritures ou à l’initialisation, ce qui peut être un processus très complexe.

Problème 2 : écritures non mises en mémoire tampon non alignées sur la taille du secteur physique

Le problème le plus simple est que les écritures non mises en mémoire tampon ne sont pas alignées sur la taille du secteur physique signalée du support de stockage. Les écritures mises en mémoire tampon, en revanche, sont alignées sur la taille de la page de 4 KB, qui coïncide avec la taille du secteur physique de la première génération de supports à grands secteurs. Cependant, la plupart des applications avec un magasin de données effectuent des écritures non mises en mémoire tampon, et devront donc s’assurer que ces écritures sont effectuées en unités de la taille du secteur physique.

Voici quelques exemples de scénarios où l’I/O résultant de l’application est désaligné :

Les enregistrements de validation sont remplis à des secteurs de 512 octets : les applications avec un magasin de données ont généralement une forme d’enregistrement de validation qui maintient soit des informations sur les modifications de métadonnées, soit la structure du magasin de données. Pour s’assurer que la perte d’un secteur n’affecte pas plusieurs enregistrements, cet enregistrement de validation est généralement rempli à une taille de secteur. Avec un disque à plus grande taille de secteur physique, l’application devra interroger la taille du secteur physique comme indiqué dans la section précédente, et s’assurer que chaque enregistrement de validation est rempli à cette taille. Avec un disque de 4K, cela garantit que les I/O ne échouent pas. Avec un disque 512e, non seulement cela évite le cycle de lecture-modification-écriture, mais cela aide à s’assurer que si un secteur physique est perdu, un seul enregistrement de validation serait perdu.
Les fichiers journaux sont écrits en segments non alignés : L’I/O non mis en mémoire tampon est généralement utilisé lors de la mise à jour ou de l’ajout à un fichier journal. Les applications peuvent soit passer à l’I/O mis en mémoire tampon, soit mettre en mémoire tampon les mises à jour du journal en interne en unités de la taille du secteur physique pour éviter les échecs d’I/O ou le déclenchement d’une lecture-modification-écriture.
Pour aider à déterminer si votre application émet des I/O non mis en mémoire tampon, assurez-vous d’inclure l’indicateur FILE_FLAG_NO_BUFFERING dans le paramètre dwFlagsAndAttributes lorsque vous appelez la fonction CreateFile.

De plus, si vous alignez actuellement les écritures sur la taille du secteur, cette taille de secteur est très probablement seulement la taille du secteur logique, car la plupart des API existantes qui interrogent la taille du secteur du support ne font qu’interroger l’unité d’adressage, c’est-à-dire la taille du secteur logique. La taille du secteur qui nous intéresse ici est la taille du secteur physique, qui est la véritable unité d’atomicité. Voici quelques exemples d’API qui récupèrent la taille du secteur logique :

• GetDiskFreeSpace, GetDiskFreeSpaceEx
• FileFsVolumeInformation
• IOCTL_DISK_GET_DRIVE_GEOMETRY, IOCTL_DISK_GET_DRIVE_GEOMETRY_EX
• IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Voici comment vous pouvez interroger la taille du secteur physique :

Méthode préférée pour Windows 8

Avec Windows 8, Microsoft a introduit une nouvelle API qui permet aux développeurs d’intégrer facilement le support 4K dans leurs applications. Cette nouvelle API prend en charge encore plus de scénarios que la méthode héritée pour Windows Vista et Windows 7 discutée ci-dessous. Cette API prend en charge ces scénarios d’appel :

• Appel depuis une application non privilégiée
• Appel à tout handle de fichier valide
• Appel à un handle de fichier sur un volume distant via SMB2
• Modèle de programmation simplifié

L’API se présente sous la forme d’une nouvelle classe d’info, FileFsSectorSizeInformation, avec la structure associée FILE_FS_SECTOR_SIZE_INFORMATION, définie comme suit :

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Méthode héritée pour Windows 7 et Windows Vista

Windows Vista et Windows Server 2008 ont introduit des API pour interroger la taille du secteur physique du dispositif de stockage attaché pour les contrôleurs de stockage basés sur AHCI. Avec Windows 7 et Windows Server 2008 R2, à partir de SP1 (ou Microsoft Knowledge Base 982018), ce support est étendu aux contrôleurs de stockage basés sur Storport. Pour un exemple de code montrant comment une application peut interroger la taille du secteur physique du volume, veuillez consulter la structure STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR.

Bien que l’exemple de code ci-dessus vous permette d’obtenir la taille du secteur physique du volume, vous devriez faire quelques vérifications de base de la taille du secteur physique signalée avant de l’utiliser, car il a été observé que certains pilotes peuvent ne pas renvoyer des données correctement formatées :

• Assurez-vous que la taille du secteur physique signalée est >= à la taille du secteur logique signalée ; si ce n’est pas le cas, votre application devrait utiliser une taille de secteur physique égale à la taille du secteur logique signalée
• Assurez-vous que la taille du secteur physique signalée est une puissance de deux ; si ce n’est pas le cas, votre application devrait utiliser une taille de secteur physique égale à la taille du secteur logique signalée
• Si la taille du secteur physique est une valeur puissance de deux entre 512 octets et 4 KB, vous devriez envisager d’utiliser une taille de secteur physique arrondie à la taille du secteur logique signalée.
• Si la taille du secteur physique est une valeur puissance de deux supérieure à 4 KB, vous devriez évaluer la capacité de votre application à gérer ce scénario avant d’utiliser cette valeur ; sinon, vous devriez envisager d’utiliser une taille de secteur physique arrondie à la baisse à 4 KB

L’utilisation de cet IOCTL pour obtenir la taille du secteur physique présente plusieurs limitations. Elle effectue les actions suivantes :

• Nécessite un privilège élevé ; si votre application ne fonctionne pas avec ce privilège, vous devrez peut-être écrire une application de service Windows comme indiqué ci-dessus
• Ne prend pas en charge les volumes SMB ; vous devrez peut-être également écrire une application de service Windows pour prendre en charge la requête de la taille du secteur physique sur ces volumes
• Ne peut pas être émise pour n’importe quel handle de fichier (l’IOCTL doit être émis pour un handle de volume).

Problème 3 : formats de fichiers dépendant de secteurs de 512 octets

Certaines applications avec des formats de fichiers standard (comme VHD 1.0) peuvent avoir ces fichiers codés en dur pour supposer une taille de secteur de 512 octets. Ainsi, les mises à jour et les écritures de ce fichier entraîneraient un cycle de lecture-modification-écriture sur le dispositif, ce qui pourrait potentiellement entraîner des problèmes de performance et de résilience pour vos clients. Cependant, il existe des moyens pour une application de fournir un support pour fonctionner sur ce type de média, par exemple :

• Utilisez la mise en mémoire tampon pour s’assurer que les écritures sont effectuées en unités de la taille du secteur physique
• Implémentez une lecture-modification-écriture interne qui peut aider à s’assurer que les mises à jour sont effectuées en unités de la taille du secteur physique signalée
• Si possible, remplissez les enregistrements jusqu’à un secteur physique, de manière à ce que le remplissage soit interprété comme un espace vide
• Envisagez de redessiner une version de la structure de données de l’application avec un support pour les secteurs plus grands

Problème 4 : la taille du secteur physique signalée peut changer entre les sessions

Il existe de nombreux scénarios où la taille du secteur physique signalée du stockage sous-jacent qui héberge le Datastor peut changer. Le plus courant de ces scénarios est lorsque vous migrez le Datastor vers un autre volume, ou même à travers le réseau. Un changement de la taille du secteur physique signalée peut être un événement inattendu pour de nombreuses applications et peut potentiellement entraîner l’échec de certaines applications à se réinitialiser.

Ce n’est pas le scénario le plus facile à supporter, et il est mentionné ici à titre consultatif. Vous devriez envisager les exigences de mobilité de vos clients et ajuster votre support en conséquence pour aider à s’assurer que les clients ne sont pas impactés négativement en utilisant des médias natifs 4K ou 512e.

Comment un utilisateur peut récupérer la taille des secteurs logiques et physiques pour un volume

Windows est livré avec une utilité pour afficher les informations de taille des secteurs pour un volume. Les versions de Windows avec fsutil pris en charge sont :

• Windows 8
• Windows Server 2012
• Windows 7 SP1 avec Microsoft KB 982018
• Windows 7 avec Microsoft KB 982018
• Windows Server 2008 R2 SP1 avec Microsoft KB 982018 (v3)
• Windows Server 2008 R2 avec Microsoft KB 982018 (v3)
• Windows Vista avec Microsoft KB 2553708
• Windows Server 2008 avec Microsoft KB 2553708

Pour obtenir les informations de taille des secteurs, appelez l’utilitaire comme suit depuis une invite de commande élevée :

fsutil fsinfo ntfsinfo <drive letter>

Un disque à secteurs 4K avec émulation de 512 octets a le champ Octets par secteur défini à 512 et le champ Octets par secteur physique défini à 4096 comme suit :

Un disque natif 4K a les champs Octets par secteur et Octets par secteur physique tous deux définis à 4096 comme suit :

Remarque

Si le champ Octet par secteur physique affiche Non pris en charge, alors soit le pilote de stockage ne prend pas en charge IOCTL_STORAGE_QUERY_PROPERTY, soit il y a eu une erreur lors de la récupération de l’info.

Ressources

• Déclaration de support général de Windows
• Microsoft KB 982018
• Correctif pour Windows 7 et Windows Server 2008 R2
• Déclaration de support HyperV
• Informations générales sur le code de contrôle IOCTL_STORAGE_QUERY_PROPERTY
• Code de contrôle IOCTL_STORAGE_QUERY_PROPERTY
• Informations générales sur la structure STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR
• Description de la terminologie standard utilisée pour décrire les mises à jour logicielles Microsoft
• Exemple de code WDK avec des détails sur la façon d’extraire les informations d’alignement d’accès au stockage signalées à partir de la structure STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR lors de l’appel du code de contrôle IOCTL_STORAGE_QUERY_PROPERTY
• Informations générales sur les options de ligne de commande ImageX
• Exigences du pilote de chipset Intel pour prendre en charge les disques à secteurs 4 KB