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

Plateforme

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

Impact des fonctionnalités

Gravité - Élevé
Fréquence - Haute

Description

Les densités Areal augmentent annuellement et, avec l’arrivée récente de 3 To de disques, les mécanismes de correction des erreurs utilisés pour traiter le rapport signal-à-bruit décroissant (SNR) sont de plus en plus inefficaces – autrement dit, une augmentation de la surcharge est nécessaire pour garantir que le média est utilisable. L’une des solutions de l’industrie du stockage pour améliorer ce mécanisme de correction d’erreurs consiste à introduire un format multimédia physique différent qui inclut une plus grande taille de secteur physique. Ce nouveau format de mé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 De format avancé sur les logiciels, explique ce que les applications peuvent faire pour aider à prendre en charge ce type de média et à discuter de l’infrastructure pour permettre aux développeurs de prendre en charge ces types d’appareils. Bien que le matériel présenté dans cette rubrique fournit des instructions pour améliorer la compatibilité avec les disques de format avancé, les informations s’appliquent généralement à tous les systèmes avec des 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 2553708 De base de connaissances Microsoft
  • Windows Server 2008 avec Microsoft KB 2553708

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

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

Taille logique et de secteur physique

L’une des préoccupations liées à l’introduction de ce changement dans le format multimédia est la compatibilité avec le logiciel et le matériel actuellement disponibles sur le marché aujourd’hui. En tant que solution temporaire, le secteur du stockage introduit initialement des disques qui émulent un disque de secteur de 512 octets standard, mais met à disposition des informations sur la taille réelle du secteur via les 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 bloc logique pour le support. 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 : l’unité pour laquelle les opérations de lecture et d’écriture sur l’appareil sont effectuées dans 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 grand secteur

L’industrie du stockage accélère rapidement la transition vers ce nouveau type de stockage avancé pour les médias avec 4 Ko de tailles de secteur physique. Deux types de médias seront publiés sur le marché :

  • 4 Ko natif : ce média n’a pas de couche d’émulation et expose directement 4 Ko comme taille logique et physique du secteur. Ce média n’est actuellement pas pris en charge par Windows et la plupart des autres systèmes d’exploitation. Toutefois, Microsoft effectue une enquête sur la faisabilité de la prise en charge de ce type de média dans une version future 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 comme taille de secteur logique (similaire à un disque normal aujourd’hui), mais rend ses informations de taille de secteur physique (4 Ko) disponibles. C’est ce que plusieurs fournisseurs de stockage introduisent actuellement sur le marché. Ce problème global lié à ce nouveau type de média est que la majorité des systèmes d’exploitation et d’application ne comprennent pas l’existence de la taille du secteur physique, ce qui peut entraîner un certain nombre de problèmes, comme indiqué 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 peuvent uniquement être écrits, ou réécrits, en unités de la taille du secteur physique. Ainsi, les écritures qui ne sont pas effectuées au niveau de cette 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 l’appareil de stockage termine l’écriture :

steps needed to upgrade datastor record within a 512-byte logical sector

Comme illustré ci-dessus, ce processus implique un certain travail par l’appareil 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 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 un appareil de stockage 512e pour effectuer 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 a été interrompu. Quelles seraient les conséquences ?

  • Étant donné que la plupart des disques durs sont mis à jour, le secteur physique ( autrement dit, la partie du support où se trouve le secteur physique) aurait pu être endommagée avec des informations incomplètes en raison d’un remplacement partiel. Mettez un autre moyen, vous pouvez le considérer comme ayant 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 possibilité de récupérer à partir d’erreurs multimédias, la perte de huit secteurs ou la perte de huit enregistrements de validation, peut potentiellement rendre impossible pour le magasin de données de récupérer avec grâce. Un administrateur peut avoir besoin de restaurer manuellement la base de données à partir d’une sauvegarde ou d’effectuer une longue reconstruction.

  • Un impact plus important est que l’acte d’une autre application entraînant un cycle en 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 données de l’autre 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 prises dans le code et sachent la distinction de taille du secteur physique logique, ainsi que 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 journaux.

Éviter de modifier l’écriture en lecture-écriture

Bien que certains fournisseurs de stockage puissent introduire certains niveaux d’atténuation dans certains appareils de stockage 512e pour essayer de faciliter les problèmes de performances et de résilience du cycle lecture-modification-écriture, il n’y a que tellement d’atténuation peut 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 à cette solution n’est pas en cours d’atténuation, mais pour que les applications fassent le bon jeu d’éléments pour éviter le cycle en 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èrent 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 ultérieures dans les limites du secteur physique. Depuis Windows Vista SP1 et Windows Server 2008, la première partition est placée au premier 1024 Ko du disque (pour les disques 4 Go ou plus, sinon l’alignement est de 64 Ko) aligné 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 vous assurer que l’alignement des partitions est décrit ci-dessous.

Les API IVdsPack::CreateVolume et IVdsPack2::CreateVolume2 n’utilisent pas le paramètre d’alignement spécifié lorsqu’un nouveau volume est créé, et utilisez plutôt la valeur d’alignement par défaut pour le système d’exploitation (pré-Windows Vista SP1 utilisera 63 octets, et post Windows Vista SP1 utilisera 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 les API IVdsCreatePartitionEx::CreatePartitionEx ou IVdsAdvancedDisk::CreatePartition API à la place, qui utilisent plutôt 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 doit prendre en compte l’alignement lors de l’exécution d’écritures ou lors de l’initialisation, ce qui peut être une matière très complexe. À compter 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 écriture en lecture-modification dans le lecteur qui peut entraîner des problèmes de performances. Les écritures mises en mémoire tampon, en revanche, sont alignées sur la taille de page ( 4 Ko) qui coïncident est la taille du secteur physique de la première génération de médias de grand secteur. Toutefois, la plupart des applications avec un magasin de données effectuent des écritures non déboguées, 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 non déboguées, vérifiez que vous incluez 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 juste la taille du secteur logique , car la plupart des API existantes qui interrogent la taille du secteur du média interrogent vraiment simplement l’unité d’adressage , autrement dit, 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 de l’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 qui détaille la façon dont une application peut interroger la taille du secteur physique du volume. L’exemple de code se trouve à l’adresse https://msdn.microsoft.com/library/ff800831.aspx.

Bien que l’exemple de code ci-dessus vous permet d’obtenir la taille du secteur physique du volume, vous devez effectuer une vérification 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 retourner correctement les données 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 valeur de puissance de deux octets comprise 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 puissance de deux valeurs 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 un privilège élevé. Si votre application n’est pas en cours d’exécution 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.

  • Impossible d’émettre un handle de fichier (iocTL doit être émis sur un handle de volume).

  • Pris en charge uniquement dans Windows versions répertoriées près du 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 des informations sur les modifications de métadonnées ou conserve la structure du magasin de données. Afin de 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 avec une plus grande taille de secteur physique, l’application doit rechercher 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. Non seulement cela évite le cycle lecture-modification-écriture, il permet de s’assurer qu’en cas de perte d’un secteur physique, un seul enregistrement de validation serait 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 s’assurer que ces mises à jour sont correctement alignées :

  • Mises à jour du journal de mémoire tampon en interne de la taille du secteur physique signalée du support d’exploitation et émettre des écritures de journal uniquement lorsqu’une unité de secteur physique est pleine
  • Utiliser des 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 (par exemple, 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înent un cycle lecture-modification-écriture sur l’appareil, ce qui entraînera potentiellement des problèmes de performances et de résilience pour vos clients. Toutefois, il existe des façons pour une application de prendre en charge l’exploitation 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 écriture en lecture-modification interne qui permet de s’assurer que les mises à jour sont effectuées en unités de la taille du secteur physique signalée
  • Si possible, remplir les enregistrements dans un secteur physique, de telle sorte que le remplissage serait interprété comme un espace vide
  • Envisagez de reconcevoir une nouvelle version de la structure de données d’application avec prise en charge des secteurs plus grands

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

Il existe de nombreux scénarios dans lesquels la taille de secteur physique signalée du stockage sous-jacent qui héberge le Datastor peut changer. Le plus courant est que vous migrez le datastor vers un autre volume, ou même 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 potentiellement entraîner l’échec de l’initialisation de certaines applications.

Ce n’est pas le scénario le plus simple à prendre en charge, et il est mentionné ici en tant qu’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 de 512 médias.

4 Ko de média natif

Le média d’émulation de 512 octets est destiné à être une étape de transition entre 512 octets natifs et 4 Ko de média natif, et nous nous attendons à ce que 4 supports natifs de 4 Ko soient publiés peu après que 512e soit disponible. Il existe plusieurs implications importantes avec ces médias qui doivent être notées :

  • Les tailles de secteur logique et physique sont à la fois de 4 Ko
  • Étant donné qu’il n’existe aucune couche d’émulation, les écritures non alignées échouent par le stockage.
  • Aucune réponse masquée n’a été atteinte : les applications fonctionnent ou ne fonctionnent pas

Bien que Microsoft étudie actuellement la prise en charge de ces types de médias dans une version ultérieure de Windows et émet un article de la Base de connaissances le cas échéant, les développeurs d’applications doivent envisager de fournir préemptivement la prise en charge de ces types de médias.

Fermeture

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

Il s’agit d’un document vivant, qui est destiné à aider les développeurs à comprendre cette transition. Vous devez commencer une conversation avec vos organisations respectives, avec les clients, les professionnels de l’informatique et vos fournisseurs de matériel pour parler de la transition du secteur de grande taille et comment cela affecte les scénarios importants pour vous.