Freigeben über

Datenträgerkompatibilitätsupdate für 512-Byte-Emulation (512e)

Plattform

Clients – Windows Vista, Windows 7, Windows 7 SP1
Servers – Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Auswirkung von Features

Schweregrad – Hoch
Auslastung – Hoch

Beschreibung

Die Flächendichte nimmt jedes Jahr zu. Mit der jüngsten Einführung von 3-TB-Festplatten werden die Fehlerkorrekturmechanismen für das abnehmende Signal-Rausch-Verhältnis (Signal-to-Noise-Ratio, SNR) flächenineffizient. Das bedeutet, dass ein erhöhter Aufwand erforderlich ist, um sicherzustellen, dass die Medien genutzt werden können. Eine der Lösungen der Speicherbranche zur Verbesserung dieses Fehlerkorrekturmechanismus besteht darin, ein anderes physisches Medienformat einzuführen, das eine größere physische Sektorgröße beinhaltet. Dieses neue physische Medienformat wird als Advanced Format bezeichnet. Daher ist es bei modernen Speichergeräten nicht mehr sicher, Annahmen hinsichtlich der Sektorgröße zu treffen, und Entwickler müssen die Annahmen untersuchen, die ihrem Code zugrunde liegen, um festzustellen, ob diese Auswirkungen haben.

In diesem Thema werden die Auswirkungen von Advanced Format-Speichergeräten auf Software beschrieben und erklärt, wie Anwendungen diese Medientypen unterstützen können. Darüber hinaus wird die Infrastruktur beschrieben, die Entwickler*innen die Unterstützung dieser Gerätetypen ermöglicht. Auch wenn in diesem Thema Anleitungen für die Verbesserung der Kompatibilität mit Advanced Format-Datenträgern bereitgestellt werden, können die Informationen grundsätzlich auf alle Systeme mit Advanced Format-Datenträgern übertragen werden. Die folgenden Versionen von Windows stellen Unterstützung für die Abfrage der Größe des physischen Sektors bereit:

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

Weitere Details finden Sie unter Microsoft-Supportrichtlinie für Festplatten mit großen Sektoren in Windows.

Weitere Informationen zu Advanced Format-Datenträgern erhalten Sie vom Anbieter Ihres Speichersystems.

Logische und physische Sektorgröße

Zu den Bedenken bei der Einführung dieser Medienformatänderung gehört die Kompatibilität mit der Software und Hardware, die aktuell auf dem Markt verfügbar ist. Als temporäre Lösung führt die Speicherbranche zunächst Datenträger ein, die einen regulären Datenträger mit 512-Byte-Sektoren emulieren, stellen jedoch über ATA- und SCSI-Standardbefehle Informationen zur tatsächlichen Sektorgröße bereit. Aufgrund dieser Emulation gibt es zwei Sektorgrößen:

  • Logischer Sektor: die Einheit, die zur logischen Blockadressierung für die Medien verwendet wird. Wir können uns dies auch als die kleinste Schreibeinheit vorstellen, die der Speicher akzeptieren kann. Dies ist die Emulation.

  • Physischer Sektor: die Einheit, für die Lese- und Schreibvorgänge auf dem Gerät in einem einzigen Vorgang abgeschlossen werden. Dies ist die „Atomic Write“-Einheit.

Die meisten aktuellen Windows-APIs, z. B. IOCTL_DISK_GET_DRIVE_GEOMETRY, geben die Größe des logischen Sektors zurück. Die Größe des physischen Sektors kann jedoch über den Steuercode IOCTL_STORAGE_QUERY_PROPERTY abgerufen werden. Dabei enthält das Feld BytesPerPhysicalSector in der Struktur STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR die relevanten Informationen. Dies wird später in diesem Artikel noch genauer behandelt.

Erste Typen von Medien mit großen Sektoren

Die Speicherbranche intensiviert ihre Anstrengungen, zu diesem neuen Advanced Format-Speichertyp für Medien mit physischen Sektorgrößen von 4 KB zu wechseln. Zwei Medientypen werden auf dem Markt veröffentlicht:

  • 4 KB nativ: Diese Medien haben keine Emulationsebene und stellen 4 KB direkt als logische und physische Sektorgröße bereit. Diese Medien werden derzeit von Windows und den meisten anderen Betriebssystemen nicht unterstützt. Microsoft untersucht jedoch die Möglichkeiten für die Unterstützung dieses Medientyps in einer zukünftigen Version von Windows und wird einen Wissensdatenbankartikel veröffentlichen, wenn angemessen.
  • 512-Byte-Emulation (512e): Diese Medien verfügen über eine Emulationsebene, wie im vorherigen Abschnitt beschrieben, und stellen 512 Byte als logische Sektorgröße bereit (ähnlich den aktuellen regulären Datenträgern), geben jedoch Informationen zur Größe des physischen Sektors (4 KB) an. Mehrere Speicheranbieter führen diesen Medientyp derzeit auf dem Markt ein. Das allgemeine Problem mit diesem neuen Medientyp besteht darin, dass die Mehrzahl der Anwendungs- und Betriebssysteme das Vorhandensein der Größe des physischen Sektors nicht versteht, was zu einer Reihe von Problemen führen kann, wie unten beschrieben.

So funktioniert die Emulation: Read-Modify-Write (RMW)

Ein Speichermedium hat eine bestimmte Einheit, anhand derer das physische Medium geändert werden kann. Dies bedeutet, die Medien können nur in Einheiten der physischen Sektorgröße geschrieben oder neu geschrieben werden. Daher erfordern Schreibvorgänge, die nicht auf dieser Einheitenebene ausgeführt werden, zusätzliche Schritte, wie im folgenden Beispiel gezeigt.

In diesem Szenario muss eine Anwendung den Inhalt eines Datastor-Datensatzes aktualisieren, der sich in einem logischen 512-Byte-Sektor befindet. Im folgenden Diagramm werden die Schritte gezeigt, die zur Durchführung des Schreibvorgangs durch das Speichergerät erforderlich sind:

Schritte zum Aktualisieren des Datastor-Datensatzes in einem logischen 512-Byte-Sektor

Wie oben dargestellt, beinhaltet dieser Prozess einige Aktionen des Speichergerät, die zu Leistungsverlusten führen können. Um diesen zusätzlichen Aufwand zu vermeiden, müssen Anwendungen aktualisiert werden, um folgende Schritte ausführen zu können:

  • Abfrage der Größe des physischen Sektors
  • Ausrichtung von Schreibvorgängen an der gemeldeten Größe des physischen Sektors

Auswirkungen von Read-Modify-Write auf die Resilienz

„Resilienz“ bezeichnet die Fähigkeit einer Anwendung, einen Zustand zwischen Sitzungen wiederherzustellen. Wir haben gesehen, was für ein 512e-Speichergerät erforderlich ist, um einen Schreibvorgang in einem 512-Byte-Sektor auszuführen – der Read-Modify-Write-Zyklus. Betrachten wir, was geschieht, wenn die Überschreibung des vorherigen physischen Sektors auf den Medien unterbrochen wurde. Was wären die Konsequenzen?

  • Da die meisten Festplatten direkt aktualisiert werden, könnte der physische Sektor (d. h. der Teil des Mediums, in dem sich der physische Sektor befunden hat) aufgrund einer teilweisen Überschreibung durch unvollständige Informationen korrumpiert worden sein. Anders ausgedrückt: Potenziell gehen alle acht logischen Sektoren verloren (die der physische Sektor logisch enthält).

  • Während die meisten Anwendungen mit einem Datenspeicher mit der Möglichkeit entworfen wurden, nach Medienfehlern wiederhergestellt zu werden, kann der Verlust von acht Sektoren (bzw. von acht Commit-Datensätzen) es möglicherweise unmöglich machen, dass der Datenspeicher ordnungsgemäß wiederhergestellt werden kann. Möglicherweise muss ein Administrator die Datenbank manuell aus einer Sicherungskopie wiederherstellen oder sogar eine längere Neuerstellung durchführen.

  • Eine weitere wichtige Auswirkung besteht darin, dass Ihre Daten möglicherweise verloren gehen, wenn eine andere Anwendung einen Read-Modify-Write-Zyklus auslöst – auch wenn Ihre Anwendung gar nicht ausgeführt wird! Dies liegt einfach daran, dass sich Ihre Daten und die Daten der anderen Anwendung im selben physischen Sektor befinden können.

Daher ist es wichtig, dass Anwendungen alle dem Code zugrundeliegenden Annahmen neu bewerten und den Unterschied zwischen der logischen und physischen Sektorgröße sowie einige interessante Kundenszenarien berücksichtigen, die weiter unten in diesem Artikel beschrieben werden.

Dieses Problem tritt wahrscheinlicher auf, wenn Ihre Anwendung auf einem Protokollstrukturdatenspeicher basiert.

Vermeiden von Read-Modify-Write

Auch wenn einige Speicheranbieter möglicherweise Maßnahmen für bestimmte 512e-Speichergeräte durchführen, um die Leistungs- und Resilienzprobleme des Read-Modify-Write-Zyklus abzuschwächen, gibt es Grenzen hinsichtlich der Workloads, die auf diese Weise behandelt werden können. Anwendungen sollten sich daher nicht langfristig auf diese Maßnahmen verlassen.

Die Lösung besteht nicht in einer Behandlung auf Datenträgerebene. Stattdessen sollten Anwendungen die richtigen Aktionen ausführen, um den Read-Modify-Write-Zyklus zu vermeiden. In diesem Abschnitt werden allgemeine Szenarien beschrieben, in denen Anwendungen Probleme mit Datenträgern mit großen Sektoren haben könnten. Für jedes dieser Probleme wird eine Möglichkeit zur Untersuchung vorgeschlagen, um es zu beheben.

Problem 1: Partition ist nicht an einer physischen Sektorgrenze ausgerichtet

Als der Administrator/der Benutzer den Datenträger partitionierte, wurde die erste Partition möglicherweise nicht auf einer ausgerichteten Grenze erstellt. Dies kann dazu führen, dass alle nachfolgenden Schreibvorgänge nicht auf physische Sektorengrenzen ausgerichtet sind. Ab Windows Vista SP1 und Windows Server 2008 wird die erste Partition auf den ersten 1024 KB des Datenträgers platziert (für Datenträger mit 4 GB oder mehr; andernfalls beträgt die Ausrichtung 64 KB), die an der Grenze eines physischen Sektors mit 4 KB ausgerichtet sind. Aufgrund der Standardpartitionierung in Windows XP, eines Partitionierungshilfsprogramms eines Drittanbieters oder einer falschen Verwendung von Windows-APIs, werden erstellte Partitionen möglicherweise nicht an einer physische Sektorgrenze ausgerichtet. Entwickler müssen sicherstellen, dass die richtigen APIs verwendet werden, um die Ausrichtung sicherzustellen. Die empfohlenen APIs, um die Partitionsausrichtung sicherzustellen, werden unten beschrieben.

Die APIs IVdsPack::CreateVolume und IVdsPack2::CreateVolume2 verwenden nicht den angegebenen Ausrichtungsparameter, wenn ein neuer Datenträger erstellt wird, sondern den Ausrichtungswert für das Betriebssystem. (Vor Windows Vista SP1 entspricht dieser Wert 63 Byte; nach Windows Vista SP1 werden die oben angegebenen Standardwerte verwendet.) Daher wird empfohlen, dass Anwendungen, die Partitionen erstellen müssen, stattdessen die APIs IVdsCreatePartitionEx::CreatePartitionEx oder IVdsAdvancedDisk::CreatePartition verwenden, die den angegebenen Ausrichtungsparameter verwenden.

Die beste Methode, um sicherzustellen, dass die Ausrichtung korrekt ist, besteht darin, sie beim anfänglichen Erstellen der Partition korrekt einzurichten. Andernfalls muss Ihre Anwendung beim Ausführen von Schreibvorgängen oder bei der Initialisierung die Ausrichtung berücksichtigen, was ein sehr komplexer Prozess sein kann. Ab Windows Vista SP1 ist dies in der Regel kein Problem. Ältere Versionen von Windows können jedoch nicht ausgerichtete Partitionen erstellen, die möglicherweise zu Leistungsproblemen mit einigen Advanced Format-Datenträgern führen.

Problem 2: Nicht gepufferte Schreibvorgänge, die nicht an der Größe des physischen Sektors ausgerichtet sind

Das grundlegende Problem besteht darin, dass nicht gepufferte Schreibvorgänge nicht an der gemeldeten physischen Sektorgröße des Speichermediums ausgerichtet sind. Hierdurch wird ein Read-Modify-Write-Zyklus auf dem Datenträger ausgelöst, was zu Leistungsproblemen führen kann. Gepufferte Schreibvorgänge werden dagegen an der Seitengröße (4 KB) ausgerichtet, was zufällig der physischen Sektorgröße von Speichermedien mit großen Sektoren der ersten Generation entspricht. Die meisten Anwendungen mit Datenspeicher führen jedoch nicht gepufferte Schreibvorgänge aus und müssen daher sicherstellen, dass diese Schreibvorgänge in Größeneinheiten des physischen Sektors ausgeführt werden.

Um zu ermitteln, ob Ihre Anwendung nicht gepufferte E/A-Vorgänge ausgibt, überprüfen Sie, ob Sie das Flag FILE_FLAG_NO_BUFFERING im Parameter dwFlagsAndAttributes gesetzt haben, wenn die Funktion CreateFile aufgerufen wird.

Wenn Sie die Schreibvorgänge derzeit an der Sektorgröße ausrichten, ist diese Sektorgröße wahrscheinlich lediglich die logische Sektorgröße, da die meisten vorhandenen APIs, die die Sektorgröße der Medien abfragen, lediglich die Adressierungseinheit abfragen, d. h. die logische Sektorgröße. Die Größe des interessierenden Sektors ist hier die physische Sektorgröße, die reale Einheit der Atomizität. Einige Beispiele für APIs, die die Größe des logischen Sektors abrufen, sind:

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

So fragen Sie die physische Sektorgröße ab

Unter https://msdn.microsoft.com/library/ff800831.aspx finden Sie ein Codebeispiel, das die Abfrage der Größe des physischen Sektors des Datenträgers durch eine Anwendung zeigt.

Im oben gezeigten Codebeispiel erfahren Sie, wie Sie die Größe des physischen Sektors eines Datenträgers abrufen. Sie sollten jedoch vor der Verwendung einige grundlegende Überprüfungen der gemeldeten physischen Sektorgröße durchführen, da einige Treiber möglicherweise keine korrekt formatierten Daten zurückgeben:

  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße >der gemeldeten logischen Sektorgröße entspricht. Wenn dies nicht der Fall ist, sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße ein Vielfaches von zwei ist. Wenn dies nicht der Fall ist, sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Wenn die physische Sektorgröße ein Vielfaches von zwei zwischen 512 Byte und 4 KB ist, sollten Sie eine physische Sektorgröße verwenden, die auf die gemeldete logische Sektorgröße aufgerundet ist.
  • Wenn die Größe des physischen Sektors ein Vielfaches von zwei größer als 4 KB ist, sollten Sie die Fähigkeit Ihrer Anwendung bewerten, dieses Szenario zu behandeln, bevor Sie diesen Wert verwenden. Wenn dies nicht der Fall ist, sollten Sie eine physische Sektorgröße verwenden, die auf 4 KB abgerundet ist.

Die Verwendung dieses IOCTL zum Abrufen der Größe des physischen Sektors unterliegt verschiedenen Einschränkungen:

  • Es sind erhöhte Berechtigungen erforderlich. Wenn Ihre Anwendung nicht mit Rechten ausgeführt wird, müssen Sie möglicherweise eine Windows-Dienstanwendung schreiben, wie oben erwähnt.

  • Es werden keine SMB-Datenträger unterstützt. Möglicherweise müssen Sie auch eine Windows-Dienstanwendung schreiben, um die Abfrage der Größe des physischen Sektors auf diesen Datenträgern zu unterstützen.

  • Kann nicht für ein Dateihandle ausgegeben werden (das IOCTL muss für ein Datenträgerhandle ausgegeben werden).

  • Wird nur von den Windows-Versionen unterstützt, die am Anfang dieses Artikels aufgeführt werden.

Commit-Datensätze werden zu 512-Byte-Sektoren aufgefüllt.

Anwendungen mit einem Datenspeicher verfügen in der Regel über eine Form von Commit-Datensatz, die entweder Informationen zu Metadatenänderungen verwaltet oder die Struktur des Datenspeichers verwaltet. Um sicherzustellen, dass sich der Verlust eines Sektors nicht auf mehrere Datensätze auswirkt, wird dieser Commit-Datensatz in der Regel zu einer Sektorgröße aufgefüllt. Bei einem Datenträger mit einer größeren physischen Sektorgröße muss die Anwendung die Größe des physischen Sektors abfragen, wie im vorherigen Abschnitt gezeigt, und sicherstellen, dass jeder Commit-Datensatz auf diese Größe aufgefüllt wird. Hierdurch wird nicht nur die Auslösung des Read-Modify-Write-Zyklus vermieden, sondern auch sichergestellt, dass bei Verlust eines physischen Sektors jeweils nur ein Commit-Datensatz verloren geht.

Protokolldateien werden in nicht ausgerichtete Blöcke geschrieben

In der Regel werden nicht gepufferte E/A-Vorgänge beim Aktualisieren oder Anfügen an eine Protokolldatei verwendet. Es gibt verschiedene Möglichkeiten, sicherzustellen, dass diese Updates ordnungsgemäß ausgerichtet sind:

  • Interne Pufferprotokollaktualisierungen für die gemeldete physische Sektorgröße des Betriebsmediums; Problemprotokollschreibvorgänge nur dann, wenn eine physische Sektoreinheit voll ist.
  • Verwenden Sie gepufferte E/A-Vorgänge.

Problem 3: Dateiformate, die auf 512-Byte-Sektoren basieren

Einige Anwendungen mit Standarddateiformaten (z. B. VHD 1.0) hartkodieren diese Dateien möglicherweise, um eine Größe mit 512-Byte-Sektoren anzunehmen. Daher führen Aktualisierungen und Schreibvorgänge für diese Datei zu einem Read-Modify-Write-Zyklus auf dem Gerät, was möglicherweise zu Leistungs- und Resilienzproblemen für Ihre Kunden führt. Es gibt jedoch Möglichkeiten für eine Anwendung, Unterstützung für den Betrieb auf diesem Medientyp bereitzustellen, z. B.:

  • Verwenden von Pufferung, um sicherzustellen, dass Schreibvorgänge in Einheiten der Größe des physischen Sektors ausgeführt werden
  • Implementieren eines internen Read-Modify-Write-Elements, mit dem sichergestellt werden kann, dass Aktualisierungen in Einheiten der gemeldeten physischen Sektorgröße ausgeführt werden
  • Wenn möglich, Padding in einem physischen Sektor, so dass das Padding als leerer Raum interpretiert wird
  • Sie könnten die Anwendungsdatenstruktur neu mit Unterstützung für größere Sektoren entwerfen.

Problem 4: Gemeldete Größe des physischen Sektors kann sich zwischen Sitzungen ändern

Es gibt viele Szenarien, in denen sich die gemeldete physische Sektorgröße des zugrunde liegenden Speichers, der den Datastor host, ändern kann. Am häufigsten ist dies beim Migrieren des Datastors auf einen anderen Datenträger oder sogar über das Netzwerk. Eine Änderung der gemeldeten Größe des physischen Sektors kann für viele Anwendungen ein unerwartetes Ereignis darstellen und sogar dazu führen, dass einige Anwendungen nicht erneut initialisiert werden.

Die Unterstützung für dieses Szenario ist nicht einfach und wird hier als Empfehlung erwähnt. Sie sollten die Mobilitätsanforderungen Ihrer Kunden berücksichtigen und Ihren Support entsprechend anpassen, um sicherzustellen, dass Kunden durch die Verwendung von 512e-Medien nicht beeinträchtigt werden.

4-KB-native Medien

512-Byte-Emulationsmedien sind als Übergangsschritt zwischen 512-Byte-nativen und 4-KB-nativen Medien vorgesehen. Wir gehen davon aus, dass 4-KB-native Medien bald nach der Verfügbarkeit von 512e veröffentlicht werden. Es gibt mehrere wichtige Auswirkungen dieser Medien, die beachtet werden sollten:

  • Die Größe des logischen und physischen Sektors beträgt jeweils 4 KB.
  • Da keine Emulationsebene vorhanden ist, schlagen nicht ausgerichtete Schreibvorgänge fehl.
  • Es gibt keine verborgenen Resilienztreffer. Anwendungen funktionieren entweder, oder sie funktionieren nicht.

Auch wenn Microsoft derzeit die Unterstützung für diese Medientypen in einer zukünftigen Version von Windows untersucht und einen Wissensdatenbankartikel veröffentlichen wird, wenn angemessen, sollten Anwendungsentwickler*innen proaktiv eine Unterstützung für diese Medientypen in Betracht ziehen.

Schließen

In diesem Artikel wurden die Auswirkungen von Medien mit großen Sektoren auf zahlreiche häufige Bereitstellungsszenarien beschrieben. Wir haben die Auswirkungen des Read-Modify-Write-Zyklus auf Leistung und Resilienz betrachtet und einige der interessanten Szenarien beschrieben, die diese Medien ermöglichen können. Außerdem haben wir auf einige Probleme hingewiesen, die diese Medien für Software verursachen können, was letztendlich die Endbenutzer*innen beeinträchtigen würde. Die Speicherbranche wechselt schnell zu Medien mit größeren Sektoren. Kunden werden daher schon bald keine Datenträger mit herkömmlichen 512-Byte-Sektoren mehr kaufen können.

Dieses Dokument ist nicht endgültig und ist als Hilfe für Entwickler*innen gedacht, um diesen Wechsel zu verstehen. Sie sollten eine Unterhaltung mit Ihren Abteilungen, Kunden, IT-Expert*innen und Hardwareanbietern beginnen, um über den Wechsel zu Datenträgern mit großen Sektoren zu sprechen und wie sich dies auf die Szenarien auswirkt, die für Sie wichtig sind.

 

 

  • Last updated on