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

  • Artikel

Plattform

Clients : Windows Vista, Windows 7, Windows 7 SP1
Server : Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1

Auswirkungen auf Features

Schweregrad : Hoch
Frequenz – Hoch

BESCHREIBUNG

Die Arealdichten nehmen jährlich zu, und mit dem kürzlichen Aufkommen von 3-TB-Datenträgern werden die Fehlerkorrekturmechanismen, die zum Umgang mit dem abnehmenden Signal-zu-Rausch-Verhältnis (SNR) verwendet werden, zu Speicherplatz ineffizient – d. h. ein erhöhter Mehraufwand ist erforderlich, um sicherzustellen, dass die Medien nutzbar sind. Eine der Lösungen der Speicherindustrie zur Verbesserung dieses Fehlerkorrekturmechanismus ist die Einführung eines anderen physischen Medienformats, das eine größere physische Sektorgröße enthält. Dieses neue Format für physische Medien wird als Erweitertes Format bezeichnet. Daher ist es nicht mehr sicher, Annahmen über die Sektorgröße moderner Speichergeräte zu treffen, und Entwickler müssen die Annahmen untersuchen, die ihrem Code zugrunde liegen, um festzustellen, ob es auswirkungen gibt.

In diesem Thema werden die Auswirkungen von Speichergeräten im erweiterten Format auf Software vorgestellt, erläutert, welche Anwendungen zur Unterstützung dieser Art von Medien beitragen können, und es wird die Infrastruktur erläutert, mit der Entwickler diese Gerätetypen unterstützen können. Während das in diesem Thema vorgestellte Material Richtlinien für die Verbesserung der Kompatibilität mit Advanced Format-Datenträgern enthält, gelten die Informationen im Allgemeinen für alle Systeme mit Datenträgern im erweiterten Format. Die folgenden Versionen von Windows bieten Unterstützung für das Abfragen der größe des physischen Sektors:

  • 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 Informationen finden Sie unter Informationen zur Microsoft-Supportrichtlinie für Großsektorlaufwerke in Windows.

Weitere Informationen zu Datenträgern im erweiterten Format erhalten Sie von Ihrem Speicheranbieter.

Logische und physische Sektorgröße

Eine der Bedenken bei der Einführung dieser Änderung des Medienformats ist die Kompatibilität mit der Software und Hardware, die derzeit auf dem Markt verfügbar ist. Als temporäre Lösung führt die Speicherbranche zunächst Datenträger ein, die einen regulären 512-Byte-Sektordatenträger emulieren, aber Mithilfe von ATA- und SCSI-Standardbefehlen Informationen über die tatsächliche Sektorgröße zur Verfügung stellen. Als Ergebnis dieser Emulation gibt es zwei Sektorgrößen:

  • Logischer Sektor: Die Einheit, die für die logische 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 ausgeführt werden. Dies ist die Einheit des atomaren Schreibvorgangs.

Die meisten aktuellen Windows-APIs, z. B. IOCTL_DISK_GET_DRIVE_GEOMETRY, geben die logische Sektorgröße zurück, aber die größe des physischen Sektors kann über den IOCTL_STORAGE_QUERY_PROPERTY-Steuerungscode abgerufen werden, wobei die relevanten Informationen im Feld BytesPerPhysicalSector in der STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR-Struktur enthalten sind. Dies wird später im Artikel ausführlicher erläutert.

Anfangstypen großer Medien

Die Speicherbranche beschleunigt die Umstellung auf diesen neuen Advanced Format-Speichertyp für Medien mit 4 KB physischer Sektorgröße. Zwei Arten von Medien werden auf den Markt gebracht:

  • 4 KB nativ: Dieses Medium verfügt über keine Emulationsebene und macht 4 KB direkt als logische und physische Sektorgröße verfügbar. Diese Medien werden derzeit von Windows und den meisten anderen Betriebssystemen nicht unterstützt. Microsoft führt jedoch eine Untersuchung der Durchführbarkeit der Unterstützung dieser Art von Medien in einer zukünftigen Version von Windows durch und wird bei Bedarf einen Knowledge Base-Artikel ausstellen.
  • 512-Byte-Emulation (512e): Dieses Medium verfügt wie im vorherigen Abschnitt beschrieben über eine Emulationsebene und macht 512 Byte als logische Sektorgröße verfügbar (ähnlich wie bei einem normalen Datenträger heute), stellt jedoch die Informationen zur physischen Sektorgröße (4 KB) zur Verfügung. Dies ist es, was mehrere Speicheranbieter derzeit auf dem Markt einführen. Dieses Allgemeine Problem bei dieser neuen Art von Medien besteht darin, dass die Mehrheit der Anwendungs- und Betriebssysteme die Existenz der physischen Sektorgröße nicht versteht, was zu einer Reihe von Problemen führen kann, wie im Folgenden erläutert wird.

Funktionsweise der Emulation: Read-Modify-Write (RMW)

Ein Speichermedium verfügt über eine bestimmte Einheit, in der das physische Medium geändert werden kann. Das heißt, die Medien können nur in Einheiten der physischen Sektorgröße geschrieben oder umgeschrieben werden. Daher erfordern Schreibvorgänge, die nicht auf dieser Lerneinheitsebene ausgeführt werden, zusätzliche Schritte, die im folgenden Beispiel beschrieben werden.

In diesem Szenario muss eine Anwendung den Inhalt eines Datastor-Datensatzes aktualisieren, der sich in einem logischen Sektor mit 512 Byte befindet. Das folgende Diagramm veranschaulicht die Schritte, die für das Speichergerät erforderlich sind, um den Schreibvorgang abzuschließen:

Erforderliche Schritte zum Aktualisieren des Datenspeicherdatensatzes innerhalb eines logischen 512-Byte-Sektors

Wie oben dargestellt, umfasst dieser Prozess einige Aufgaben des Speichergeräts, die zu einem Leistungsverlust führen können. Um diese zusätzliche Arbeit zu vermeiden, müssen Anwendungen aktualisiert werden, um Folgendes zu tun:

  • Abfrage für die Größe des physischen Sektors.
  • Stellen Sie sicher, dass Schreibvorgänge an der gemeldeten physischen Sektorgröße ausgerichtet sind.

Auswirkungen auf die Resilienz von Read-Modify-Write

Resilienz spricht von der Fähigkeit einer Anwendung, den Zustand zwischen Sitzungen wiederherzustellen. Wir haben gesehen, was für ein 512e-Speichergerät erforderlich ist, um einen 512-Byte-Sektorschreibvorgang auszuführen – den Lese-/Änderungs-Schreibzyklus. Sehen wir uns an, was passieren würde, wenn der Prozess des Überschreibens des vorherigen physischen Sektors auf den Medien unterbrochen würde. Was wären die Folgen?

  • Da die meisten Festplattenlaufwerke aktualisiert werden, könnte der physische Sektor – d. h. der Teil der Medien, auf dem sich der physische Sektor befand – aufgrund einer teilweisen Überschreibung mit unvollständigen Informationen beschädigt werden. Anders ausgedrückt: Sie können sich vorstellen, dass möglicherweise alle 8 logischen Sektoren verloren gegangen sind (die der physische Sektor logisch enthält).

  • Während die meisten Anwendungen mit einem Datenspeicher so konzipiert sind, dass sie nach Medienfehlern wiederhergestellt werden können, kann der Verlust von acht Sektoren oder anders ausgedrückt, der Verlust von acht Commitdatensätzen eine ordnungsgemäße Wiederherstellung des Datenspeichers möglicherweise unmöglich machen. Ein Administrator muss die Datenbank möglicherweise manuell aus einer Sicherung wiederherstellen oder sogar eine längere Neuerstellung durchführen.

  • Eine weitere wichtige Auswirkung ist, dass die Aktion einer anderen Anwendung, die einen Lese-/Änderungs-Schreibzyklus verursacht, möglicherweise dazu führen kann, dass Ihre Daten verloren gehen – auch wenn Ihre Anwendung nicht ausgeführt wird! Dies liegt einfach daran, dass sich Ihre Daten und die Daten der anderen Anwendung innerhalb desselben physischen Sektors befinden können.

Vor diesem Hintergrund ist es wichtig, dass die Anwendungssoftware alle annahmen im Code übernommenen Annahmen neu bewertet und sich der Größenunterschiede zwischen logisch und physischem Sektor sowie einigen interessanten Kundenszenarien bewusst ist, die später in diesem Artikel erläutert werden.

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

Vermeiden von Lese-/Änderungs-Schreibvorgängen

Während einige Speicheranbieter möglicherweise einige Stufen der Entschärfung auf bestimmten 512e-Speichergeräten einführen, um die Leistungs- und Resilienzprobleme des Lese-/Änderungs-Schreibzyklus zu verringern, gibt es nur so viel, was die Entschärfung in Bezug auf die Workload bewältigen kann. Daher sollten Sich Anwendungen nicht auf diese Entschärfung als langfristige Lösung verlassen.

Die Lösung hierfür besteht nicht in der Laufwerksminderung, sondern darin, Dass Anwendungen die richtigen Schritte ausführen, um den Lese-Änderung-Schreib-Zyklus zu vermeiden. In diesem Abschnitt werden häufige Szenarien erläutert, in denen Anwendungen Probleme mit datenträgern großen Sektoren haben können, und es wird eine Möglichkeit zur Untersuchung vorgeschlagen, um die einzelnen Probleme zu beheben.

Problem 1: Die Partition ist nicht an einer physischen Sektorgrenze ausgerichtet.

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

Die APIs IVdsPack::CreateVolume und IVdsPack2::CreateVolume2 verwenden nicht den angegebenen Ausrichtungsparameter, wenn ein neues Volume erstellt wird, und verwenden stattdessen den Standardausrichtungswert für das Betriebssystem (Pre-Windows Vista SP1 verwendet 63 Byte, und 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 Möglichkeit, um sicherzustellen, dass die Ausrichtung korrekt ist, besteht darin, dies beim ersten Erstellen der Partition richtig zu tun. Andernfalls muss Ihre Anwendung die Ausrichtung beim Ausführen von Schreibvorgängen oder bei der Initialisierung berücksichtigen – was eine sehr komplexe Angelegenheit 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 bei einigen Advanced Format-Datenträgern führen können.

Problem 2: Ungepufferte Schreibvorgänge, die nicht an der größe des physischen Sektors ausgerichtet sind

Das grundlegende Problem besteht darin, dass ungepufferte Schreibvorgänge nicht an der gemeldeten physischen Sektorgröße des Speichermediums ausgerichtet sind, wodurch ein Read-Modify-Write auf dem Laufwerk ausgelöst wird, was zu Leistungsproblemen führen kann. Gepufferte Schreibvorgänge hingegen werden an der Seitengröße – 4 KB – ausgerichtet, die zufällig der physischen Sektorgröße der ersten Generation großer Sektormedien entspricht. Die meisten Anwendungen mit einem Datenspeicher führen jedoch ungepufferte Schreibvorgänge durch und müssen daher sicherstellen, dass diese Schreibvorgänge in Einheiten der physischen Sektorgröße ausgeführt werden.

Um festzustellen, ob Ihre Anwendung ungepufferte E/A-Vorgänge ausgibt, überprüfen Sie, ob Sie das FILE_FLAG_NO_BUFFERING-Flag in den dwFlagsAndAttributes-Parameter einschließen, wenn Sie die CreateFile-Funktion aufrufen.

Wenn Sie die Schreibvorgänge derzeit an der Sektorgröße ausrichten, entspricht diese Sektorgröße höchstwahrscheinlich nur der logischen Sektorgröße, da die meisten vorhandenen APIs, die die Sektorgröße der Medien abfragen, tatsächlich nur die Adressierungseinheit abfragen – d. h. die logische Sektorgröße. Die Sektorgröße, die hier von Interesse ist, ist die größe des physischen Sektors, die die reale Einheit der Atomarität ist. Einige Beispiele für APIs, die die logische Sektorgröße abrufen, sind:

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

Abfragen der Größe des physischen Sektors

Microsoft hat auf MSDN ein Codebeispiel bereitgestellt, in dem beschrieben wird, wie eine Anwendung die physische Sektorgröße des Volumes abfragen kann. Das Codebeispiel befindet sich unter https://msdn.microsoft.com/library/ff800831.aspx.

Mit dem obigen Codebeispiel können Sie zwar die physische Sektorgröße des Volumes abrufen, doch sollten Sie eine grundlegende Überprüfung der gemeldeten physischen Sektorgröße durchführen, bevor Sie es verwenden, da einige Treiber möglicherweise nicht ordnungsgemäß formatierte Daten zurückgeben:

  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße = die gemeldete logische Sektorgröße ist >. Andernfalls sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße eine Leistung von zwei beträgt. Andernfalls sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Wenn die physische Sektorgröße ein Zwei-Leistungswert zwischen 512 Bytes und 4 KB ist, sollten Sie die Verwendung einer physischen Sektorgröße in Betracht ziehen, die auf die gemeldete logische Sektorgröße gerundet ist.
  • Wenn die physische Sektorgröße einen Zwei-Leistungs-Wert größer als 4 KB ist, sollten Sie die Fähigkeit Ihrer Anwendung, dieses Szenario zu verarbeiten, bewerten, bevor Sie diesen Wert verwenden. Andernfalls sollten Sie eine auf 4 KB gerundete physische Sektorgröße in Erwägung ziehen.

Die Verwendung dieses IOCTL zum Abrufen der physischen Sektorgröße hat mehrere Einschränkungen:

  • Erfordert erhöhte Berechtigungen. Wenn Ihre Anwendung nicht mit Berechtigungen ausgeführt wird, müssen Sie möglicherweise eine Windows-Dienstanwendung schreiben, wie oben beschrieben.

  • SMB-Volumes werden nicht unterstützt. Möglicherweise müssen Sie auch eine Windows-Dienstanwendung schreiben, um abfragen von physischer Sektorgröße auf diesen Volumes zu unterstützen.

  • Kann nicht für ein Dateihandle ausgestellt werden (die IOCTL muss für ein Volume Handle ausgestellt werden).

  • Wird nur in windows-Versionen unterstützt, die am Anfang dieses Artikels aufgeführt sind.

Commitdatensätze sind auf 512-Byte-Sektoren gepolstert.

Anwendungen mit einem Datenspeicher verfügen in der Regel über eine Form von Commitdatensatz, der entweder Informationen zu Metadatenänderungen verwaltet oder die Struktur des Datenspeichers beibehält. Um sicherzustellen, dass sich der Verlust eines Sektors nicht auf mehrere Datensätze auswirkt, wird dieser Commitdatensatz in der Regel auf eine Sektorgröße aufgepolstert. Bei einem Datenträger mit einer größeren physischen Sektorgröße muss die Anwendung die physische Sektorgröße abfragen, wie im vorherigen Abschnitt gezeigt, und sicherstellen, dass jeder Commitdatensatz auf diese Größe aufgefüllt ist. Dadurch wird nicht nur der Lese-, Änderungs- und Schreibzyklus vermieden, es trägt auch dazu bei, dass im Falle eines Verlusts eines physischen Sektors nur ein Commitdatensatz verloren geht.

Protokolldateien werden in nicht ausgerichtete Blöcke geschrieben

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

  • Interne Pufferprotokollaktualisierungen der gemeldeten physischen Sektorgröße der Betriebsmedien und Ausgabeprotokollschreibvorgänge nur dann, wenn eine physische Sektoreinheit voll ist
  • Verwenden von gepufferten E/A-Vorgängen

Problem 3: Dateiformate, die auf 512-Byte-Sektoren angewiesen sind

Bei einigen Anwendungen mit Standarddateiformaten (z. B. VHD 1.0) sind diese Dateien möglicherweise hartcodiert, um eine Sektorgröße von 512 Byte anzunehmen. Daher würden Updates und Schreibvorgänge für diese Datei zu einem Lese-/Änderungs-Schreibzyklus auf dem Gerät führen, was zu Leistungs- und Resilienzbedenken für Ihre Kunden führen kann. Es gibt jedoch Möglichkeiten für eine Anwendung, unterstützung für den Betrieb auf diesem Medientyp bereitzustellen, z. B.:

  • Verwenden sie Pufferung, um sicherzustellen, dass Schreibvorgänge in Einheiten der physischen Sektorgröße ausgeführt werden.
  • Implementieren eines internen Read-Modify-Write-Werts, mit dem sichergestellt werden kann, dass Updates in Einheiten der gemeldeten physischen Sektorgröße ausgeführt werden
  • Wenn möglich, zeichnet das Pad in einen physischen Sektor auf, so dass die Füllung als leerer Raum interpretiert wird.
  • Erwägen Sie, eine neue Version der Anwendungsdatenstruktur mit Unterstützung für größere Sektoren neu zu gestalten.

Problem 4: Die 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 hostet, ändern kann. Dies ist am häufigsten, wenn Sie den Datastor zu einem anderen Volume oder sogar über das Netzwerk migrieren. Eine Änderung der gemeldeten physischen Sektorgröße kann für viele Anwendungen ein unerwartetes Ereignis sein und kann dazu führen, dass einige Anwendungen sogar nicht erneut initialisiert werden können.

Dies ist nicht das einfachste Szenario, das unterstützt werden kann, 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 keine negativen Auswirkungen haben.

Native Medien mit 4 KB

512-Byte-Emulationsmedien sind als Übergangsschritt zwischen nativen 512-Byte- und 4 KB-nativen Medien gedacht, und wir erwarten, dass 4 KB-native Medien bald nach der Verfügbarkeit von 512e veröffentlicht werden. Es gibt mehrere wichtige Auswirkungen auf diese Medien, die beachtet werden sollten:

  • Die logischen und physischen Sektorgrößen betragen jeweils 4 KB.
  • Da keine Emulationsebene vorhanden ist, tritt beim Speicher ein Fehler bei nicht ausgerichteten Schreibvorgängen auf.
  • Keine versteckte Resilienz trifft – Anwendungen funktionieren entweder oder sie funktionieren nicht

Obwohl Microsoft derzeit die Unterstützung für diese Medientypen in einer zukünftigen Version von Windows untersucht und ggf. einen KB-Artikel ausgibt, sollten Anwendungsentwickler in Erwägung ziehen, präventiv Unterstützung für diese Medientypen bereitzustellen.

Schließen

In diesem Artikel haben wir die Auswirkungen erläutert, die große Branchenmedien mit vielen gängigen Bereitstellungsszenarien einführen. Wir haben die Auswirkungen von Read-Modify-Write auf die Leistung und Resilienz gesehen, einige der interessanten Szenarien, die diese Medien einführen können, und die Reihe von Problemen, die sie möglicherweise mit Software verursachen können, was sich letztendlich auf den Endbenutzer auswirkt. Die Speicherbranche wandelt sich schnell auf Medien mit größeren Branchengrößen um, und schon bald werden Kunden keine Datenträger mit herkömmlichen 512-Byte-Branchengrößen kaufen können.

Dies ist ein lebendiges Dokument und soll Entwicklern helfen, diesen Übergang zu verstehen. Sie sollten ein Gespräch mit Ihren jeweiligen Organisationen, mit Kunden, IT-Experten und Ihren Hardwareanbietern beginnen, um über den großen Sektorwechsel zu sprechen und darüber zu sprechen, wie sich dies auf die Für Sie wichtigen Szenarien auswirkt.