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

Plattform

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

Auswirkung von Features

Schweregrad: Hoch
Häufigkeit – Hoch

BESCHREIBUNG

Arealdichten nehmen jährlich zu, und mit der kürzlichen Einführung von 3-TB-Datenträgern werden die Fehlerkorrekturmechanismen, die zur Behandlung des abnehmenden Signal-zu-Rausch-Verhältnisses (SNR) verwendet werden, ineffizient– d. h. es ist ein erhöhter Mehraufwand erforderlich, um sicherzustellen, dass die Medien verwendet werden können. Eine der Speicherbranchelösungen zur Verbesserung dieses Fehlerkorrekturmechanismus ist die Einführung eines anderen physischen Medienformats, das eine größere physische Sektorgröße umfasst. Dieses neue physische Medienformat heißt Erweitertes Format. Daher ist es nicht mehr sicher, Annahmen zur Sektorgröße moderner Speichergeräte zu treffen, und Entwickler müssen die Annahmen untersuchen, die ihrem Code zugrunde liegt, um festzustellen, ob es Auswirkungen gibt.

In diesem Thema werden die Auswirkungen von Advanced Format-Speichergeräten auf Software 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 zur Verbesserung der Kompatibilität mit Datenträgern im erweiterten Format enthält, gelten die Informationen im Allgemeinen für alle Systeme mit Datenträgern im erweiterten Format. Die folgenden Versionen von Windows unterstützung für die Abfrage der physischen Sektorgröße:

  • 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ürLaufwerke mit großen Sektoren in Windows.

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

Logische und physische Sektorgröße

Eines der Bedenken bei der Einführung dieser Änderung im Medienformat 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 Informationen zur tatsächlichen Sektorgröße über ATA- und SCSI-Standardbefehle verfügbar machen. Als Ergebnis dieser Emulation gibt es zwei Sektorgrößen:

  • Logischer Sektor: Die Einheit, die für die logische Block adressierung für die Medien verwendet wird. Wir können uns dies auch als die kleinste Schreibeinheit überlegen, die der Speicher akzeptieren kann. Dies ist die Emulation.

  • Physischer Sektor: Die Einheit, für die Lese- und Schreibvorgänge für das Gerät in einem einzigen Vorgang abgeschlossen werden. Dies ist die Einheit des atomaren Schreibzugriffs.

Die meisten aktuellen Windows-APIs, z. B. IOCTL _ DISK GET DRIVE _ _ _ GEOMETRY, geben die logische Sektorgröße zurück. Die physische Sektorgröße kann jedoch über den IOCTL _ STORAGE QUERY _ PROPERTY-Steuerungscode _ abgerufen werden. Die relevanten Informationen sind im Feld BytesPerPhysicalSector in der _ _ _ DESCRIPTOR-Struktur SPEICHERZUGRIFFSAUSRICHTUNG enthalten. Dies wird weiter oben in diesem Artikel ausführlicher erläutert.

Anfangstypen von Medien für große Sektoren

Die Speicherbranche weiterentwickelt sich schnell zu diesem neuen Speichertyp "Advanced Format" für Medien mit physischen Sektorgrößen von 4 KB. Zwei Medientypen werden auf dem Markt veröffentlicht:

  • 4 KB nativ: Dieses Medium verfügt über keine Emulationsebene und macht direkt 4 KB als logische und physische Sektorgröße verfügbar. Dieses Medium wird derzeit nicht von Windows und den meisten anderen Betriebssystemen unterstützt. Microsoft führt jedoch eine Untersuchung der Elastizität durch, diese Art von Medien in einer zukünftigen Version von Windows zu unterstützen, und gibt gegebenenfalls einen Knowledge Base aus.
  • 512-Byte-Emulation (512e): Dieses Medium verfügt über eine Emulationsebene, wie im vorherigen Abschnitt erläutert, und macht 512 Byte als logische Sektorgröße verfügbar (ähnlich wie ein regulärer Datenträger heute), stellt aber seine physischen Sektorgrößeninformationen (4 KB) zur Verfügung. Dies wird derzeit von mehreren Speicheranbietern auf dem Markt eingeführt. Dieses allgemeine Problem bei dieser neuen Art von Medien ist, dass die Mehrheit der Anwendungen und Betriebssysteme das Vorhandensein der physischen Sektorgröße nicht versteht. Dies kann zu einer Reihe von Problemen führen, wie im Folgenden erläutert.

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, das Medium kann nur in Einheiten der physischen Sektorgröße geschrieben oder umgeschrieben werden. Daher sind für Schreibvorgänge, die nicht auf dieser Einheitenebene ausgeführt werden, zusätzliche Schritte erforderlich, die im folgenden Beispiel beschrieben werden.

In diesem Szenario muss eine Anwendung den Inhalt eines Datastor-Datensatzes aktualisieren, der sich in einem logischen 512-Byte-Sektor befindet. Das folgende Diagramm veranschaulicht die Erforderlichen Schritte, damit das Speichergerät den Schreibzugriff abschließen kann:

Schritte, die zum Aktualisieren des Datastor-Datensatzes innerhalb eines logischen 512-Byte-Sektor erforderlich sind

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

  • Abfragen der physischen Sektorgröße.
  • Stellen Sie sicher, dass Schreibvorgänge an der gemeldeten physischen Sektorgröße ausgerichtet sind.

Auswirkungen von Lese-/Änderungs-/Schreibzugriff auf die Resilienz

Resilienz spricht von der Fähigkeit, dass eine Anwendung den Zustand zwischen Sitzungen wiederherstellen kann. Wir haben gesehen, was für ein 512e-Speichergerät erforderlich ist, um einen 512-Byte-Sektor-Schreibzyklus durchzuführen– den Lese-/Änderungs-Schreibzyklus. Sehen wir uns an, was passieren würde, wenn der Vorgang zum Überschreiben des vorherigen physischen Sektor auf den Medien unterbrochen würde. Was wären die Konsequenzen?

  • Da die meisten Festplattenlaufwerke an Ort und Stelle aktualisiert werden, könnte der physische Sektor – also der Teil des Mediums, auf dem sich der physische Sektor befand – aufgrund einer teilweisen Überschreibung mit unvollständigen Informationen beschädigt worden sein. Anders ausgedrückt: Sie können sich dies so denken, als ob alle acht 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 potenziell verhindern, dass der Datenspeicher ordnungsgemäß wiederhergestellt werden kann. 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 der Schritt 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 Sektor befinden könnten.

Vor diesem Hintergrund ist es wichtig, dass die Anwendungssoftware alle annahmen im Code neu auswertet und sich der Unterscheidung nach der Größe des logischen und physischen Sektor sowie einigen interessanten Kundenszenarien bewusst ist, die weiter oben in diesem Artikel erläutert werden.

Dieses Problem tritt wahrscheinlicher auf, wenn Ihre Anwendung auf einem Protokollstruktur-Datenspeicher basiert.

Vermeiden von Lese-/Änderungs-/Schreibzugriff

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

Die Lösung dafür ist keine Laufwerkminderung, sondern die Anwendung muss den richtigen Satz von Maßnahmen zur Vermeidung des Lese-/Änderungs-/Schreibzyklus verwenden. In diesem Abschnitt werden häufige Szenarien erläutert, in denen Anwendungen Probleme mit großen Sektordatenträgern haben können, und es wird ein Untersuchungsweg 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 physische Sektorgrenzen ausgerichtet werden. Ab Windows Vista SP1 und Windows Server 2008 wird die erste Partition auf den ersten 1024 KB des Datenträgers platziert (bei Datenträgern mit mindestens 4 GB, andernfalls ist die Ausrichtung 64 KB), die an einer physischen Sektorgrenze von 4 KB ausgerichtet ist. Aufgrund der Standardpartitionierung in Windows XP, einem Drittanbieter-Partitionierungs-Hilfsprogramm oder einer falschen Verwendung von Windows-APIs, werden erstellte Partitionen jedoch 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 sicherzustellen, dass die Partitionsausrichtung unten beschrieben wird.

Die IVdsPack::CreateVolume- und IVdsPack2::CreateVolume2-APIs verwenden nicht den angegebenen Ausrichtungsparameter, wenn ein neues Volume erstellt wird, sondern verwenden stattdessen den Standardausrichtungswert für das Betriebssystem (Pre-Windows Vista SP1 verwendet 63 Bytes, und nach Windows Vista SP1 werden die oben genannten Standardwerte verwendet). Daher wird empfohlen, dass Anwendungen, die Partitionen erstellen müssen, stattdessen die IVdsCreatePartitionEx::CreatePartitionEx- oder IVdsAdvancedDisk::CreatePartition-APIs verwenden, die den angegebenen Ausrichtungsparameter verwenden.

Die beste Möglichkeit, um sicherzustellen, dass die Ausrichtung korrekt ist, besteht in der richtigen Erstellung der Partition. Andernfalls muss Ihre Anwendung beim Ausführen von Schreibvorgängen oder bei der Initialisierung die Ausrichtung berücksichtigen. Dies kann sehr komplex sein. Ab Windows Vista SP1 ist dies im Allgemeinen kein Problem. Ältere Versionen von Windows können jedoch nicht ausgerichtete Partitionen erstellen, die bei einigen Datenträgern im erweiterten Format zu Leistungsproblemen führen können.

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

Das grundlegende Problem ist, dass nicht gepufferte Schreibvorgänge nicht an der gemeldeten physischen Sektorgröße des Speichermediums ausgerichtet sind. Dies löst einen Lese-/Änderungs-/Schreibzugriff auf dem Laufwerk aus, der zu Leistungsproblemen führen kann. Gepufferte Schreibvorgänge sind dagegen an der Seitengröße von 4 KB ausgerichtet. Dies entspricht zufällig der physischen Sektorgröße der ersten Generation großer Sektormedien. Die meisten Anwendungen mit einem Datenspeicher führen jedoch ungepufferte Schreibvorgänge aus und müssen daher sicherstellen, dass diese Schreibvorgänge in Einheiten der physischen Sektorgröße ausgeführt werden.

Um zu ermitteln, ob Ihre Anwendung ungepufferte E/A-Probleme auft, überprüfen Sie, ob Sie beim Aufrufen der CreateFile-Funktion das Flag FILE FLAG NO _ _ _ BUFFERING in den dwFlagsAndAttributes-Parameter einordnen.

Wenn Sie die Schreibvorgänge derzeit an der Sektorgröße ausrichten, ist diese Sektorgröße wahrscheinlich nur die größe des logischen Sektores, da die meisten vorhandenen APIs, die die Sektorgröße der Medien abfragen, tatsächlich nur die Adressierungseinheit abfragen , also die größe des logischen Sektors. Die sektorspezifische Größe ist hier die physische Sektorgröße, die die echte Einheit der Atomarität ist. Einige Beispiele für APIs, die die logische Sektorgröße abrufen:

  • GetDiskFreeSpace, GetDiskFreeSpaceEx
  • FileFsVolumeInformation
  • IOCTL _ DISK _ GET _ DRIVE _ GEOMETRY, IOCTL _ DISK GET DRIVE _ _ _ GEOMETRY _ EX
  • IVdsDisk::GetProperties, IVdsDisk3::GetProperties2

Abfragen der physischen Sektorgröße

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

Im obigen Codebeispiel können Sie zwar die physische Sektorgröße des Volumes erhalten. Sie sollten jedoch vor der Verwendung einige grundlegende Überprüfungen der Physischen Sektorgröße ausführen, da festgestellt wurde, dass einige Treiber möglicherweise nicht ordnungsgemäß formatierte Daten zurückgeben:

  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße >= der gemeldeten logischen Sektorgröße ist. Wenn dies nicht der Wert 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 eine Zweierleistung hat. Wenn dies nicht der Wert ist, sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Wenn die physische Sektorgröße ein Zweierleistungswert zwischen 512 Byte und 4 KB ist, sollten Sie erwägen, eine physische Sektorgröße zu verwenden, die auf die gemeldete logische Sektorgröße aufgerundet wird.
  • Wenn die größe des physischen Sektor ein Zweierleistungswert größer als 4 KB ist, sollten Sie die Fähigkeit Ihrer Anwendung bewerten, dieses Szenario zu verarbeiten, bevor Sie diesen Wert verwenden. Andernfalls sollten Sie erwägen, eine physische Sektorgröße zu verwenden, die auf 4 KB aufgerundet ist.

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

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

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

  • Kann nicht für ein Dateihandles ausgegeben werden (die IOCTL muss für ein Volumehandles ausgegeben werden).

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

Commitdatensätze werden auf 512-Byte-Sektoren aufschlossen.

Anwendungen mit einem Datenspeicher verfügen in der Regel über eine Art Commitdatensatz, der entweder Informationen zu Metadatenänderungen verwaltet oder die Struktur des Datenspeichers verwaltet. Um sicherzustellen, dass der Verlust eines Sektor nicht mehrere Datensätze betrifft, wird dieser Commitdatensatz in der Regel auf eine Sektorgröße auflagert. 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 aufschlossen ist. Dadurch wird nicht nur der Lese-/Änderungs-/Schreibzyklus vermieden, sondern auch sichergestellt, dass im Fall eines Verlusts eines physischen Sektor nur ein Commitdatensatz verloren geht.

Protokolldateien werden in nicht ausgerichteten Blocken in geschrieben.

Nicht gepufferte E/A wird 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:

  • Puffern Sie Protokollupdates intern auf die gemeldete physische Sektorgröße der Betriebsmedien, und geben Sie Protokoll-Schreibvorgänge nur aus, wenn eine physische Sektoreinheit voll ist.
  • Gepufferte E/A verwenden

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

Einige Anwendungen mit Standarddateiformaten (z. B. VHD 1.0) verfügen möglicherweise über hart codierte Dateien, um eine Sektorgröße von 512 Byte vorauszugehen. Daher würden Updates und Schreibvorgänge in dieser Datei zu einem Lese-/Änderungs-/Schreibzyklus auf dem Gerät führen, was möglicherweise zu Leistungs- und Resilienzbedenken für Ihre Kunden führen würde. Es gibt jedoch Möglichkeiten für eine Anwendung, Unterstützung für die Verwendung dieser Art von Medien zu bieten, z. B.:

  • Verwenden Sie die Pufferung, um sicherzustellen, dass Schreibvorgänge in Einheiten der physischen Sektorgröße ausgeführt werden.
  • Implementieren Sie einen internen Lese-/Änderungs-/Schreibzugriff, mit dem sichergestellt werden kann, dass Updates in Einheiten der gemeldeten physischen Sektorgröße ausgeführt werden.
  • Wenn möglich, werden Datensätze in einem physischen Sektor so aufschlossen, dass die Aufleerung als leerer Bereich interpretiert wird.
  • Erwägen Sie das Umgestalten einer neuen Version der Anwendungsdatenstruktur mit Unterstützung für größere Sektoren.

Problem 4: Die gemeldete Größe des physischen Sektor 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. Am häufigsten wird datastor zu einem anderen Volume oder sogar über das Netzwerk migriert. Eine Änderung der gemeldeten physischen Sektorgröße kann für viele Anwendungen ein unerwartetes Ereignis sein und dazu führen, dass einige Anwendungen möglicherweise sogar nicht erneut initialisiert werden.

Dies ist nicht das einfachste Zu unterstützende Szenario 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 nicht durch die Verwendung von 512e-Medien negativ eingeschränkt werden.

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 512e verfügbar sind. Es gibt mehrere wichtige Auswirkungen auf dieses Medium, die beachtet werden sollten:

  • Die Logische und physische Sektorgröße beträgt 4 KB.
  • Da es keine Emulationsebene gibt, kann der Speicher nicht ausgerichtete Schreibvorgänge nicht erstellen.
  • Keine verborgene Resilienz– Anwendungen funktionieren entweder oder funktionieren nicht

Obwohl Microsoft derzeit die Unterstützung für diese Medientypen in einer zukünftigen Version von Windows untersucht und gegebenenfalls einen KB-Artikel ausausgabe wird, sollten Anwendungsentwickler erwägen, diese Medientypen präemptiv zu unterstützen.

Schließen

In diesem Artikel haben wir die Auswirkungen erläutert, die große Sektormedien mit vielen gängigen Bereitstellungsszenarien einführen. Wir haben die Auswirkungen von Read-Modify-Write auf die Leistung und Resilienz, einige interessante Szenarien, die diese Medien einführen können, und die Reihe von Problemen gesehen, die sie möglicherweise mit Software verursachen können, was sich letztendlich auf den Endbenutzer auswirken kann. Die Speicherbranche geht schnell zu Medien mit größeren Sektorgrößen über, und sehr bald können Kunden keine Datenträger mit herkömmlichen 512-Byte-Sektorgrößen erwerben.

Dies ist ein dokumenterlebenses Dokument und als Hilfe für Entwickler gedacht, um diesen Übergang zu verstehen. Sie sollten eine Unterhaltung mit Ihren jeweiligen Organisationen, mit Kunden, IT-Profis und Ihren Hardwareanbietern beginnen, um über den großen Sektorübergang und seine Auswirkungen auf die für Sie wichtigen Szenarien zu sprechen.