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

  • Article

Plateformes

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 compatibilité de disque d’émulation de 512 octets (512e) publiée pour Windows 7 SP1 et Windows Server 2008 R2 SP1. Cette mise à jour contient de nombreuses nouvelles informations, dont certaines s’appliquent uniquement aux Windows 8 et Windows Server 2012.

Les densités d’Areal augmentent chaque année et, avec l’avènement récent des disques de 3 To, les mécanismes de correction des erreurs utilisés pour gérer le rapport signal/bruit (SNR) décroissant deviennent inefficaces dans l’espace; C’est-à-dire qu’une surcharge accrue est nécessaire pour s’assurer que le média est utilisable. L’une des solutions du secteur du stockage pour améliorer ce mécanisme de correction des erreurs consiste à introduire un format de média physique différent qui inclut une plus grande taille de secteur physique. Ce nouveau format multimédia physique est appelé Format avancé. Par conséquent, il n’est plus sûr de faire des hypothèses concernant la taille du secteur des appareils de stockage modernes, et les développeurs devront étudier les hypothèses sous-jacentes à leur code pour déterminer s’il y a un impact.

Cette rubrique présente l’effet des périphériques de stockage au format avancé sur les logiciels, explique ce que les applications peuvent faire pour aider à prendre en charge ce type de média et décrit 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 d’appareils. Bien que les documents présentés dans cette rubrique fournissent des instructions pour améliorer la compatibilité avec les disques de format avancé, les informations s’appliquent généralement à tous les systèmes dotés de disques de format avancé exécutant Windows Vista, Windows 7 et Windows 8.

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

La liste ci-dessous récapitule les nouvelles fonctionnalités fournies dans le cadre de Windows 8 et de Windows Server 2012 pour aider à améliorer l’expérience des clients et des développeurs avec des disques de secteur volumineux. Une description plus détaillée de chaque élément est décrite ci-dessous.

  • 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 de la boîte de réception pour les disques avec une taille de secteur de 4 Ko sans émulation (4K Native). Voici quelques-uns des scénarios et applications pris en charge :
    • Possibilité d’installer Windows sur un disque de secteur 4K et de démarrer à partir d’un disque de secteur 4K sans émulation (disque natif 4K)
    • 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 émis pour n’importe quel handle de fichier
    • Disponible pour les applications non privilégiées
    • Modèle d’utilisation plus convivial
  • Inclut l’utilitaire de ligne de commande fsutil amélioré pour interroger la taille de secteur logique et physique du volume avec des informations d’alignement (la version de base de l’utilitaire sans informations d’alignement est disponible pour Windows 7 avec Microsoft KB 982018 et Windows Server 2008 R2 avec Microsoft KB 982018)

Présentation des disques de format avancé (4K)

L’un des problèmes liés à l’introduction de ce changement dans le format multimédia est le risque d’introduire des problèmes de compatibilité avec les logiciels et le matériel existants. En tant que solution de compatibilité temporaire, le secteur du stockage introduit initialement des disques qui émulent un disque de secteur de 512 octets standard, mais mettent à disposition des informations sur la taille réelle du secteur via les commandes ATA et SCSI standard. À la suite de cette émulation, il existe essentiellement deux tailles de secteur :

Secteur logique : Unité utilisée pour l’adressage de blocs logiques pour le média. Nous pouvons également le considérer comme la plus petite unité d’écriture que le stockage peut accepter. Il s’agit de l’émulation.
Secteur physique : Unité pour laquelle les opérations de lecture et d’écriture sur l’appareil sont effectuées en une seule opération. Il s’agit de l’unité d’écriture atomique.
La plupart des API Windows actuelles, telles que IOCTL_DISK_GET_DRIVE_GEOMETRY retournent 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 dans la structure STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR . Ceci est abordé plus en détail plus loin dans l’article.

Types initiaux de médias de grande taille

Le secteur du stockage intensifie rapidement ses efforts pour passer à ce nouveau type de stockage format avancé pour les supports ayant une taille de secteur physique de 4 Ko. Deux types de médias seront mis sur le marché :

4 Ko natif : Ce média 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 média est que la majorité des applications et des systèmes d’exploitation n’interrogent pas et n’alignent pas les E/S sur la taille du secteur physique, ce qui peut entraîner des échecs d’E/S inattendus.
Émulation de 512 octets (512e) : Ce média a une couche d’émulation comme indiqué dans la section précédente et expose 512 octets en tant que taille de secteur logique (similaire à un disque standard aujourd’hui), mais rend ses informations de taille de secteur physique (4 Ko) disponibles. Le problème général avec ce nouveau type de média est que la majorité des systèmes d’application et 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 l’aborderons ci-dessous.
Prise en charge globale de Windows pour les médias de grande taille

Ce tableau documente la politique officielle de support Microsoft pour différents médias et les tailles de secteur signalées qui en résultent. Pour plus d’informations, consultez cet article de la Base de connaissances.

Noms communs Taille de secteur logique signalée Taille du secteur physique signalée Version de Windows avec support
Natif de 512 octets, 512n 512 octets 512 octets Toutes les versions de Windows
Format avancé, 512e, AF, émulation de 512 octets 512 octets 4 Ko Windows Vista avec ms Kb 2553708
Windows Server 2008* avec MS KB 2553708
Windows 7 w/ MS KB 982018
Windows Server 2008 R2* avec MS KB 982018
Toutes les versions de Windows à partir de Windows 7 SP1 et versions ultérieures.
Toutes les versions de serveur de Server 2008 R2 SP1 et ultérieures.

*À l’exception d’Hyper-V. Consultez la section « Exigences de prise en charge des applications pour les lecteurs de grande taille ».
Advance Format, AF, 4K Native, 4Kn 4 Ko 4 Ko Toutes les versions de Windows à partir de Windows 8 et au-delà
Toutes les versions de serveur à partir de Windows Server 2012 et au-delà
Autres Pas 4 Ko ou 512 octets Pas 4 Ko ou 512 octets Non pris en charge

Notes

Bien qu’il ne soit pas mis en évidence dans le tableau précédent, Windows XP, Windows Server 2003 et Windows Server 2003 R2 ne prennent pas en charge les médias 512e ou 4 Kon. Bien que le système puisse démarrer et être en mesure de fonctionner au minimum, il peut y avoir des scénarios inconnus de problèmes de fonctionnalité, de perte de données ou de performances sous-optimales. Par conséquent, Microsoft met fortement en garde contre l’utilisation d’un média 512e avec Windows XP ou d’autres produits basés sur le code base de Windows XP (par exemple, Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP Édition 64 bits, Windows XP Embedded, Windows Small Business Server 2003 et Windows Small Business Server 2003 R2).

Fonctionnement de l’émulation : lecture-modification-écriture (RMW)

Un support de stockage a une certaine unité dans laquelle le support physique peut être modifié. Autrement dit, le média ne peut être écrit, ou réécrit, qu’en unités de la taille du secteur physique. Par conséquent, les écritures qui ne sont pas effectuées à ce niveau d’unité nécessitent des étapes supplémentaires, que nous allons parcourir 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 termine l’écriture :

étapes pour qu’un périphérique de stockage effectue une écriture

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

  • Requête pour la taille du secteur physique
  • Vérifier que les écritures sont alignées sur la taille de secteur physique signalée

Bien que cela ne semble initialement être qu’un problème de performances, il peut y avoir un problème plus grave. Nous allons en parler dans la section suivante.

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

La résilience parle de la capacité d’une application à récupérer l’état entre les sessions. Nous avons vu ce qui est nécessaire pour qu’un périphérique de stockage 512e effectue un cycle lecture-modification-écriture dans un secteur de 512 octets. Voyons ce qui se passerait si le processus de remplacement du secteur physique précédent sur les médias était interrompu. Quelles seraient les conséquences?

  • Étant donné que la plupart des lecteurs de disque dur sont mis à jour sur place, le secteur physique, c’est-à-dire la partie du média où se trouvait le secteur physique, a pu être endommagé avec des informations incomplètes en raison d’un remplacement partiel. Autrement dit, vous pouvez le considérer comme ayant potentiellement perdu les 8 secteurs logiques (que le secteur physique contient logiquement).
  • Alors que la plupart des applications avec un magasin de données sont conçues avec la possibilité de récupérer après des erreurs de média, la perte de huit secteurs, ou autrement dit, la perte de huit enregistrements de validation, peut potentiellement rendre impossible la récupération normale du magasin de données. Un administrateur peut avoir besoin de restaurer manuellement la base de données à partir d’une sauvegarde ou peut même avoir besoin d’effectuer une longue reconstruction.
  • Un autre impact important est que l’action d’une autre application à l’origine d’un cycle 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 les autres données de l’application peuvent se trouver dans le même secteur physique.

Dans cet esprit, il est important que les logiciels d’application réévaluent toutes les hypothèses retenues dans le code et soient conscients de la distinction de taille de secteur logique-physique, ainsi que de certains scénarios clients intéressants décrits plus loin dans cet article.

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

Bien que certains fournisseurs de stockage puissent introduire certains niveaux d’atténuation au sein de certains appareils de stockage 512e pour essayer de réduire les problèmes de performances et de résilience du cycle Lecture-modification-écriture, il n’y a qu’un grand nombre d’atténuations à gérer en termes de charge de travail. Par conséquent, les applications ne doivent pas s’appuyer sur cette atténuation comme solution à long terme. En outre, il n’y a aucune garantie que toutes les classes de disques auront cette atténuation en place, ni que l’atténuation est bien conçue.

La solution à ce problème n’est pas l’atténuation dans le lecteur, mais la conception d’applications pour effectuer l’ensemble approprié de choses pour aider à prendre en charge ce type de média. Cette section décrit les scénarios courants dans lesquels les applications peuvent rencontrer des problèmes avec des disques de secteur volumineux, et suggère une avenue d’investigation pour essayer de résoudre chaque problème.

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

Lorsque l’administrateur/l’utilisateur partitionne le disque, la première partition n’a peut-être pas été créée sur une limite alignée. Cela peut entraîner la non-alignement de toutes les écritures suivantes sur les limites du secteur physique. À compter de Windows Vista SP1 et Windows Server 2008, la première partition est placée à la première 1 024 Ko du disque (pour les disques de 4 Go ou plus, sinon l’alignement est de 64 Ko) qui est alignée sur une limite de secteur physique de 4 Ko. Toutefois, étant donné le partitionnement par défaut dans Windows XP, un utilitaire de partitionnement tiers ou une utilisation incorrecte des API Windows, les partitions créées peuvent ne pas être alignées sur une limite de secteur physique. Les développeurs devront s’assurer que les API appropriées sont utilisées pour garantir l’alignement. Les API recommandées pour 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 pour le système d’exploitation (pré-Windows Vista SP1 utilise 63 octets, et après Windows Vista SP1 utilise les valeurs par défaut indiquées ci-dessus). Utilisez plutôt les API IVdsCreatePartitionEx::CreatePartitionEx ou IVdsAdvancedDisk::CreatePartition qui utilisent le paramètre d’alignement spécifié pour les applications qui doivent créer des partitions.

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

Problème 2 : les écritures non déboguées ne sont pas alignées sur la taille du secteur physique

Le problème le plus simple est que les écritures non chiffrées ne sont pas alignées sur la taille de secteur physique signalée du support de stockage. En revanche, les écritures mises en mémoire tampon sont alignées sur la taille de page de 4 Ko, qui correspond par coïncidence à la taille du secteur physique de la première génération de médias de secteur volumineux. Toutefois, la plupart des applications disposant d’un magasin de données effectuent des écritures sans débogage et doivent donc s’assurer que ces écritures sont effectuées en unités de la taille du secteur physique.

Voici quelques exemples de scénarios dans lesquels les E/S d’application résultantes ne sont pas alignées :

Les enregistrements de validation sont remplis en secteurs de 512 octets : Les applications avec un magasin de données ont généralement une forme d’enregistrement de validation qui conserve des informations sur les modifications de métadonnées ou maintient 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 ajouté à une taille de secteur. Avec un disque avec une plus grande taille de secteur physique, l’application doit interroger la taille du secteur physique, comme indiqué dans la section précédente, et vérifier que chaque enregistrement de validation est rempli à cette taille. Avec un disque 4K, cela garantit que les E/S n’échouent pas. Avec un disque de 512e, non seulement cela évite le cycle lecture-modification-écriture, mais permet de s’assurer qu’en cas de perte d’un secteur physique, un seul enregistrement de validation est perdu.
Les fichiers journaux sont écrits dans des blocs non alignés : Les E/S non déboguées sont généralement utilisées lors de la mise à jour ou de l’ajout à un fichier journal. Les applications peuvent soit basculer vers les E/S mises en mémoire tampon, soit mettre en mémoire tampon en interne les mises à jour du journal sur des unités de la taille du secteur physique pour éviter les échecs d’E/S ou déclencher une lecture-modification-écriture.
Pour déterminer si votre application émet des E/S non déboguées, veillez à inclure l’indicateur FILE_FLAG_NO_BUFFERING dans le paramètre dwFlagsAndAttributes lorsque vous appelez la fonction CreateFile.

En outre, si vous alignez actuellement les écritures sur la taille du secteur, cette taille de secteur est probablement simplement la taille de secteur logique, car la plupart des API existantes qui interrogent la taille de secteur du média interrogent simplement l’unité d’adressage, c’est-à-dire la taille du secteur logique. La taille du secteur d’intérêt ici est la taille du secteur physique, qui est l’unité réelle 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 la prise en charge 4K dans leurs applications. Cette nouvelle API prend en charge un nombre encore plus élevé de scénarios que la méthode héritée pour Windows Vista et Windows 7 décrite ci-dessous. Cette API active les scénarios d’appel suivants :

  • Appel à partir d’une application non privilégiée
  • Appel à n’importe quel 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’informations, 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 périphérique de stockage attaché pour les contrôleurs de stockage basés sur AHCI. Avec Windows 7 et Windows Server 2008 R2, à compter de SP1 (ou 982018 de la Base de connaissances Microsoft), cette prise en charge est étendue aux contrôleurs de stockage storport. Microsoft a fourni un exemple de code sur MSDN détaillant comment une application peut interroger la taille du secteur physique du volume.

Bien que l’exemple de code ci-dessus vous permette d’obtenir la taille du secteur physique du volume, vous devez effectuer une vérification de base de la taille du secteur physique signalé avant de l’utiliser, car il a été observé que certains pilotes peuvent ne pas retourner des données correctement mises en forme :

  • Assurez-vous que la taille du secteur physique signalée est >= la taille de secteur logique signalée; si ce n’est pas le cas, votre application doit utiliser une taille de secteur physique égale à la taille de 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 doit utiliser une taille de secteur physique égale à la taille de secteur logique signalée
  • Si la taille du secteur physique est une valeur de puissance de 2 entre 512 octets et 4 Ko, vous devez envisager d’utiliser une taille de secteur physique arrondie à la taille de secteur logique signalée.
  • Si la taille du secteur physique est supérieure à 4 Ko, vous devez évaluer la capacité de votre application à gérer ce scénario avant d’utiliser cette valeur ; sinon, vous devez envisager d’utiliser une taille de secteur physique arrondie à 4 Ko

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

  • Nécessite des privilèges élevés ; si votre application ne s’exécute pas avec des privilèges, 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 l’interrogation de la taille du secteur physique sur ces volumes
  • Ne peut pas être émis pour un handle de fichier (l’IOCTL doit être émis sur un handle de volume)

Problème 3 : formats de fichiers reposant sur des secteurs de 512 octets

Certaines applications avec des formats de fichier 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 dans ce fichier entraîneraient un cycle Lecture-Modification-Écriture sur l’appareil, ce qui pourrait entraîner des problèmes de performances et de résilience pour vos clients. Toutefois, il existe des moyens pour une application de fournir la prise en charge du fonctionnement sur ce type de média, par exemple :

  • Utiliser la mise en mémoire tampon pour vous assurer que les écritures sont effectuées en unités de la taille du secteur physique
  • Implémenter une lecture-modification-écriture interne qui peut vous aider à garantir que les mises à jour sont effectuées en unités de la taille de secteur physique signalée
  • Si possible, pad enregistre dans un secteur physique, de telle sorte que le remplissage soit interprété comme un espace vide
  • Envisagez de reconcevoir une version de la structure de données de l’application avec prise en charge de secteurs plus importants

Problème 4 : la taille du secteur physique signalée peut changer d’une session à l’autre

Il existe de nombreux scénarios dans lesquels la taille du secteur physique signalée du stockage sous-jacent qui héberge l’entrepôt de données peut changer. La plus courante d’entre elles est lorsque vous migrez l’entrepôt de données vers un autre volume, voire sur le réseau. Une modification de la taille du secteur physique signalée peut être un événement inattendu pour de nombreuses applications et peut entraîner l’échec de la réin initialisation de certaines applications.

Ce scénario n’est pas le plus facile à prendre en charge et est mentionné ici comme un avis. Vous devez prendre en compte les exigences de mobilité de vos clients et ajuster votre support en conséquence pour vous assurer que les clients ne sont pas affectés négativement par l’utilisation d’un média natif 4K ou 512e.

Comment un utilisateur peut récupérer la taille de secteur logique et physique d’un volume

L’utilitaire intégré avec Windows permet d’afficher les informations de taille de secteur d’un volume. Les versions de Windows avec fsutil pris en charge sont les suivantes :

  • 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 sur la taille du secteur, appelez l’utilitaire comme suit à partir d’une invite de commandes avec élévation de privilèges :

fsutil fsinfo ntfsinfo <drive letter>

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

octets par secteur et par secteur physique d’un disque de secteur de 4 Ko avec émulation de 512 octets

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

Octets par secteur et par secteur physique d’un disque natif de 4 Ko

Notes

Si le champ Octet par secteur physique affiche Non pris en charge, le pilote de stockage ne prend pas en charge IOCTL_STORAGE_QUERY_PROPERTY ou une erreur s’est produite lors de la récupération des informations.

Ressources