Mise à jour de la compatibilité des disques Émulation 512 octets (512e)

  • Article

Plateforme

Clients - Windows Vista, Windows 7, Windows 7 SP1
Serveurs - Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Impact sur les fonctionnalités

Gravité - Élevée
Fréquence - Élevée

Description

Les densités Areal augmentent chaque année, et avec l’avènement récent des disques de 3 To, les mécanismes de correction d’erreurs utilisés pour traiter le rapport signal/bruit (SNR) décroissant sont de plus en plus inefficaces dans l’espace, c’est-à-dire qu’une surcharge accrue est nécessaire pour garantir l’utilisation du média. L’une des solutions du secteur du stockage pour améliorer ce mécanisme de correction des erreurs consiste à introduire un format multimé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 de leur code pour déterminer s’il y a un impact.

Cette rubrique présente l’effet des appareils de stockage au format avancé sur les logiciels, décrit ce que les applications peuvent faire pour aider à prendre en charge ce type de média et décrit l’infrastructure permettant 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é. Les versions suivantes de Windows prennent en charge l’interrogation de la taille du secteur physique :

  • Windows 7 avec Microsoft KB 982018
  • Windows 7 SP1
  • Windows Server 2008 R2 avec Microsoft KB 982018
  • Windows Server 2008 R2 SP1
  • Windows Vista avec Microsoft KB 2553708
  • Windows Server 2008 avec Microsoft KB 2553708

Pour plus d’informations, consultez Informations sur la stratégie de support Microsoft pour les lecteurs de grande taille dans Windows.

Pour plus d’informations sur les disques de format avancé, contactez votre fournisseur de stockage.

Taille de secteur logique ou physique

L’une des préoccupations lors de l’introduction de ce changement dans le format multimédia est la compatibilité avec les logiciels et le matériel actuellement disponibles sur le marché. En tant que solution 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 par le biais de commandes ATA et SCSI standard. À la suite de cette émulation, il existe 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 décrit 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 au format avancé pour les médias avec des tailles de secteur physique de 4 Ko. Deux types de médias seront mis sur le marché :

  • 4 Ko native : ce média n’a pas de couche d’émulation et expose directement 4 Ko en tant que taille de secteur logique et physique. Ce média n’est actuellement pas pris en charge par Windows et la plupart des autres systèmes d’exploitation. Toutefois, Microsoft mène une enquête sur la faisabilité de la prise en charge de ce type de média dans une prochaine version de Windows et émettra un article de la Base de connaissances le cas échéant.
  • É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 met à disposition ses informations de taille de secteur physique (4 Ko). C’est ce que plusieurs fournisseurs de stockage introduisent actuellement sur le marché. Ce problème global 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.

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, les médias ne peuvent être écrits, ou réécrits, 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 suivant.

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

étapes nécessaires pour mettre à niveau un enregistrement datastor au sein d’un secteur logique de 512 octets

Comme illustré ci-dessus, ce processus implique un 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 effectuer les opérations suivantes :

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

Impact de la résilience 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 une écriture de secteur de 512 octets , le cycle Lecture-modification-écriture. Examinons ce qui se passerait si le processus de remplacement du secteur physique précédent sur les médias était interrompu. Quelles en seraient les conséquences ?

  • Étant donné que la plupart des disques durs se mettent à jour en place, le secteur physique (c’est-à-dire la partie du média où se trouvait le secteur physique) aurait 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).

  • Bien que la plupart des applications disposant d’un magasin de données soient conçues avec la possibilité de récupérer à partir d’erreurs multimédias, la perte de huit secteurs, ou autrement dit, la perte de huit enregistrements de validation, peut potentiellement empêcher la récupération du magasin de données correctement. Un administrateur peut avoir besoin de restaurer manuellement la base de données à partir d’une sauvegarde ou même 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 celles de l’autre application peuvent se trouver dans le même secteur physique.

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

Ce problème est plus susceptible de se produire si votre application s’appuie sur un magasin de données de structure de journal.

Éviter la lecture-modification-écriture

Bien que certains fournisseurs de stockage introduisent certains niveaux d’atténuation au sein de certains appareils de stockage 512e pour tenter d’atténuer 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.

La solution n’est pas l’atténuation dans le lecteur, mais le fait que les applications fassent le bon ensemble de choses pour éviter le cycle lecture-modification-écriture. Cette section décrit les scénarios courants où les applications peuvent avoir 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. À partir de Windows Vista SP1 et De 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) 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 doivent 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 post-Windows Vista SP1 utilise les valeurs par défaut indiquées ci-dessus). Par conséquent, il est recommandé que les applications qui doivent créer des partitions utilisent plutôt les API IVdsCreatePartitionEx::CreatePartitionEx ou IVdsAdvancedDisk::CreatePartition , qui utilisent le paramètre d’alignement spécifié.

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 tenir compte de l’alignement lors de l’exécution d’écritures ou lors de l’initialisation, ce qui peut être très complexe. À partir de Windows Vista SP1, ce n’est généralement pas un problème ; toutefois, les versions antérieures de Windows peuvent créer des partitions non alignées qui peuvent potentiellement entraîner des problèmes de performances avec certains disques de format avancé.

Problème 2 : Écritures non alignées sur la taille du secteur physique

Le problème de base est que les écritures non chiffrées ne sont pas alignées sur la taille de secteur physique signalée du support de stockage, ce qui déclenche une lecture-modification-écriture dans le lecteur qui peut entraîner des problèmes de performances. D’autre part, les écritures mises en mémoire tampon sont alignées sur la taille de page (4 Ko) qui correspond, par coïncidence, à la taille du secteur physique de la première génération de grands médias de secteur. 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.

Pour déterminer si votre application émet des E/S sans débogage, case activée pour voir que vous incluez 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 correspond probablement uniquement à la taille du secteur logique , car la plupart des API existantes qui interrogent la taille du 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

Comment interroger la taille du secteur physique

Microsoft a fourni un exemple de code sur MSDN détaillant la façon dont une application peut interroger la taille du secteur physique du volume. L’exemple de code se trouve dans https://msdn.microsoft.com/library/ff800831.aspx.

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 du 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 puissance de deux valeurs comprises 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 une valeur puissance de deux 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 ce IOCTL pour obtenir la taille du secteur physique présente plusieurs limitations :

  • 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 taille de secteur physique sur ces volumes.

  • Ne peut pas être émis pour un handle de fichier (le IOCTL doit être émis sur un handle de volume).

  • Pris en charge uniquement dans les versions de Windows répertoriées au début de cet article.

Les enregistrements de validation sont ajoutés à des secteurs de 512 octets

Les applications avec un magasin de données ont généralement une forme d’enregistrement de validation qui conserve les informations sur les modifications des métadonnées ou maintient la structure du magasin de données. Pour garantir 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 taille de secteur physique supérieure, 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 ajouté à cette taille. Non seulement cela évite-t-il le cycle Lecture-modification-écriture, mais il permet de garantir 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 chiffrées sont généralement utilisées lors de la mise à jour ou de l’ajout à un fichier journal. Il existe plusieurs façons de vous assurer que ces mises à jour sont correctement alignées :

  • Mise à jour du journal de la mémoire tampon interne de la taille de secteur physique signalée du support d’exploitation, et le journal des problèmes écrit uniquement lorsqu’une unité de secteur physique est pleine
  • Utiliser les E/S mises en mémoire tampon

Problème 3 : Formats de fichiers s’appuyant sur des 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 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 prendre en charge le fonctionnement sur ce type de média, par exemple :

  • Utilisez 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 garantir que les mises à jour sont effectuées en unités de la taille de secteur physique signalée
  • Dans la mesure du possible, le pad enregistre dans un secteur physique, de telle sorte que le remplissage soit interprété comme un espace vide
  • Envisagez de reconcevoir une nouvelle version de la structure de données d’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 le datastor peut changer. La plus courante d’entre elles est lorsque vous migrez le datastor 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 n’est pas le scénario le plus simple à prendre en charge, et est mentionné ici comme un conseil. Vous devez tenir compte des exigences de mobilité de vos clients et ajuster votre support en conséquence pour vous assurer que les clients ne sont pas impactés négativement par l’utilisation du média 512e.

Média natif de 4 Ko

Le média d’émulation de 512 octets est conçu comme une étape de transition entre le média natif de 512 octets et le média natif de 4 Ko, et nous nous attendons à voir 4 Ko de média natif publié peu après la disponibilité de 512e. Il y a plusieurs implications importantes pour ce média qui doivent être notées :

  • Les tailles de secteur logique et physique sont de 4 Ko
  • Étant donné qu’il n’existe aucune couche d’émulation, les écritures non alignées seront échouées par le stockage
  • Pas d’accès à la résilience masquée : les applications fonctionnent ou ne fonctionnent pas

Bien que Microsoft étudie actuellement la prise en charge de ces types de médias dans une prochaine version de Windows et qu’il émettra un article de base de connaissances le cas échéant, les développeurs d’applications doivent envisager de fournir une prise en charge préventive pour ces types de médias.

Fermeture

Dans cet article, nous avons abordé les effets que les grands médias du secteur introduisent avec de nombreux scénarios de déploiement courants. Nous avons vu l’impact sur les performances et la résilience de lecture-modification-écriture, certains des scénarios intéressants que ce média peut introduire, ainsi que l’ensemble des problèmes qu’ils peuvent potentiellement causer avec les logiciels, ce qui affecte finalement l’utilisateur final. L’industrie du stockage passe rapidement à des médias avec des tailles de secteur plus importantes, et très bientôt les clients ne pourront pas acheter de disques avec des tailles de secteur de 512 octets traditionnelles.

Il s’agit d’un document dynamique destiné à aider les développeurs à comprendre cette transition. Vous devez commencer une conversation avec vos organisations respectives, avec des clients, des professionnels de l’informatique et vos fournisseurs de matériel pour discuter de la transition du secteur à grande échelle et de la façon dont elle affecte les scénarios qui sont importants pour vous.