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

Featureeffekt

Schweregrad – Hoch
Häufigkeit - Hoch

BESCHREIBUNG

Die Arealdichte wird jährlich erhöht, und mit der jüngsten Einführung von 3 TB-Datenträgern werden die Fehlerkorrekturmechanismen, die zum Umgang mit dem verringerten Signal-to-Noise-Ratio (SNR) verwendet werden, zu einem ineffizienten Raum – das heißt, eine erhöhte Menge an Aufwand ist erforderlich, um sicherzustellen, dass die Medien nutzbar sind. Eine der Lösungen für die Speicherindustrie zur Verbesserung dieses Fehlerkorrekturmechanismus besteht darin, ein anderes physisches Medienformat einzuführen, das eine größere physische Sektorgröße enthält. Dieses neue physische Medienformat wird als Advanced Format bezeichnet. Daher ist es nicht mehr sicher, annahmen über die Branchengröße moderner Speichergeräte zu machen, und Entwickler müssen die Annahmen untersuchen, die ihrem Code zugrunde liegen, um festzustellen, ob eine Auswirkung besteht.

In diesem Thema wird die Wirkung von Advanced Format-Speichergeräten auf Software vorgestellt, erläutert, was Anwendungen tun können, um diese Art von Medien zu unterstützen, und erläutert die Infrastruktur, um Entwicklern die Unterstützung dieser Gerätetypen zu ermöglichen. Während das in diesem Thema vorgestellte Material Richtlinien zur Verbesserung der Kompatibilität mit Advanced Format-Datenträgern bereitstellt, gelten die Informationen im Allgemeinen für alle Systeme mit Advanced Format-Datenträgern. Die folgenden Versionen von Windows unterstützen 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 Details finden Sie unter Informationen zur Microsoft-Supportrichtlinie für große Laufwerke in Windows.

Weitere Informationen zu Advanced Format-Datenträgern wenden Sie sich an Ihren Speicheranbieter.

Logischer vs. physischer Sektorgröße

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

  • Logischer Sektor: Die Einheit, die für die logische Blockansprache für die Medien verwendet wird. Wir können es auch als kleinste Schreibeinheit denken, die der Speicher akzeptieren kann. Dies ist die Emulation.

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

Die meisten aktuellen Windows-APIs, z. B. IOCTL_DISK_GET_DRIVE_GEOMETRY, geben die logische Sektorgröße zurück, aber die physische Sektorgröße kann über den IOCTL_STORAGE_QUERY_PROPERTY-Steuerelementcode abgerufen werden, wobei die relevanten Informationen im Feld BytesPerPhysicalSector in der STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR-Struktur enthalten sind. Dies wird weiter unten im Artikel erläutert.

Anfängliche Arten von Großen Branchenmedien

Die Speicherindustrie hat schnell anstrengungen unternommen, um zu diesem neuen Advanced Format-Typ des Speichers für Medien mit 4 KB physischen Branchengrößen zu wechseln. Zwei Medientypen werden auf dem Markt veröffentlicht:

  • 4 KB Native: Diese Medien haben keine Emulationsschicht und stellen direkt 4 KB als logische und physische Sektorgröße zur Verfügung. Diese Medien werden derzeit von Windows und den meisten anderen Betriebssystemen nicht unterstützt. Microsoft führt jedoch eine Untersuchung zur Machbarkeit der Unterstützung dieser Art von Medien in einer zukünftigen Version von Windows durch und stellt bei Bedarf einen Knowledge Base-Artikel aus.
  • 512-Byte-Emulation (512e): Diese Medien verfügen über eine Emulationsebene wie im vorherigen Abschnitt erläutert und 512-Bytes als logische Sektorgröße (ähnlich wie ein regulärer Datenträger heute) verfügbar macht, macht aber seine physischen Brancheninformationen (4 KB) verfügbar. Dies ist, was mehrere Speicheranbieter derzeit auf den Markt bringen. Dieses allgemeine Problem mit dieser neuen Art von Medien ist, dass die Mehrheit der Anwendungs- und Betriebssysteme die Existenz der physischen Sektorgröße nicht verstehen, was zu einer Reihe von Problemen führen kann, wie unten beschrieben.

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 des physischen Sektors geschrieben oder neu geschrieben werden. Daher erfordern Schreibvorgänge, die nicht auf dieser Einheitsebene ausgeführt werden, zusätzliche Schritte, die wir im folgenden Beispiel durchlaufen werden.

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

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

Wie oben dargestellt, umfasst dieser Prozess einige Arbeit durch das Speichergerät, das zu einem Leistungsverlust führen kann. Um diese zusätzliche Arbeit zu vermeiden, müssen Anwendungen aktualisiert werden, um folgendes auszuführen:

  • Abfrage für die physische Sektorgröße.
  • Stellen Sie sicher, dass Schreibvorgänge an die gemeldete physische Sektorgröße ausgerichtet sind.

Die Ausfallsicherheit des Lese-Änderungs-Schreibzugriffs

Die 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-Sektor schreiben zu können – der Read-Modify-Write-Zyklus. Sehen wir uns an, was passiert wäre, wenn der Prozess des Überschreibens des vorherigen physischen Sektors auf den Medien unterbrochen wurde. Was wäre die Folgen?

  • Da die meisten Festplatten an Ort und Stelle aktualisiert werden, könnte der physische Sektor – das heißt, der Teil der Medien, in denen sich der physische Sektor befindet – aufgrund eines teilweisen Überschreibens beschädigt worden sein. Stellen Sie sich eine andere Art und Weise vor, dass sie potenziell alle 8 logischen Sektoren verloren hat (was der physische Sektor logisch enthält).

  • Die meisten Anwendungen mit einem Datenspeicher sind mit der Möglichkeit konzipiert, Medienfehler wiederherzustellen, die Verlust von acht Sektoren oder eine andere Möglichkeit, den Verlust von acht Commit-Datensätzen, kann es möglicherweise unmöglich machen, dass der Datenspeicher ordnungsgemäß wiederhergestellt werden kann. Ein Administrator muss die Datenbank möglicherweise manuell aus einer Sicherung wiederherstellen oder sogar einen langen Neuaufbau durchführen.

  • Eine weitere wichtige Auswirkung besteht darin, dass der Akt 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 Ihre Daten und die Daten der anderen Anwendung in derselben physischen Branche liegen könnten.

In diesem Sinne ist es wichtig, dass Anwendungssoftware alle Annahmen im Code neu bewertet und sich der logischen Größe des Sektors sowie einigen interessanten Kundenszenarien bewusst sind, die später in diesem Artikel erläutert wurden.

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

Vermeiden von Lese-Änderungs-Schreibzugriff

Während einige Speicheranbieter einige Minderungsstufen innerhalb bestimmter 512e-Speichergeräte einführen können, um die Leistung und Resilienzprobleme des Lese-Änderungs-Schreibzyklus zu erleichtern, gibt es nur so viel Gegenmaßnahmen in Bezug auf Arbeitslasten. Anwendungen sollten sich daher nicht auf diese Entschärfung als langfristige Lösung verlassen.

Die Lösung für dies ist keine In-Drive-Entschärfung, sondern die richtigen Anwendungen, um den Lese-Änderungs-Schreibzyklus zu vermeiden. In diesem Abschnitt werden allgemeine Szenarien erläutert, in denen Anwendungen möglicherweise Probleme mit großen Datenträgern haben, und schlägt eine Möglichkeit der Untersuchung vor, um jedes Problem zu beheben.

Problem 1: Die Partition wird nicht an eine physische 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 an physische Branchengrenzen ausgerichtet werden. Ab Windows Vista SP1 und Windows Server 2008 wird die erste Partition an der ersten 1024 KB des Datenträgers (für Datenträger 4 GB oder größer) platziert, andernfalls ist die Ausrichtung 64 KB, die an eine 4 KB-physische Sektorgrenze ausgerichtet ist. Angesichts der standardmäßigen Partitionierung in Windows XP, einem 3.-Party-Partitionierungs-Hilfsprogramm oder einer falschen Verwendung von Windows APIs werden erstellte Partitionen möglicherweise nicht an eine physische 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.

Das IVdsPack::CreateVolume- und IVdsPack2:CreateVolume2-APIs verwenden nicht den angegebenen Ausrichtungsparameter, wenn ein neues Volume erstellt wird, und verwenden Sie stattdessen den Ausrichtungswert für das Betriebssystem (Pre-Windows Vista SP1 verwendet 63 Bytes, und post Windows Vista SP1 verwendet die oben angegebenen Standardwerte). Daher wird empfohlen, anwendungen, die Partitionen erstellen müssen, verwenden die IVdsCreatePartitionEx::CreatePartitionEx oder IVdsAdvancedDisk::CreatePartition APIs stattdessen , die den angegebenen Ausrichtungsparameter verwenden.

Die beste Möglichkeit, sicherzustellen, dass die Ausrichtung richtig ist, besteht darin, sie beim anfänglichen Erstellen der Partition zu erledigen. Andernfalls muss Ihre Anwendung die Ausrichtung bei der Ausführung von Schreibvorgängen oder bei der Initialisierung berücksichtigen – dies kann eine sehr komplexe Angelegenheit sein. Ab Windows Vista SP1 ist dies im Allgemeinen 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 können.

Problem 2: Nicht gebufferte Schreibvorgänge, die nicht an physische Sektorgröße ausgerichtet sind

Das grundlegende Problem besteht darin, dass unbufferte Schreibvorgänge nicht an die gemeldete physische Sektorgröße des Speichermediums ausgerichtet sind, wodurch ein Read-Modify-Write im Laufwerk ausgelöst wird, das zu Leistungsproblemen führen kann. Gepufferte Schreibvorgänge werden andererseits an die Seitengröße – 4 KB – ausgerichtet, die zufällig die physische Sektorgröße der ersten Generation großer Branchenmedien darstellt. Die meisten Anwendungen mit einem Datenspeicher führen jedoch unbufferte Schreibvorgänge aus und müssen daher sicherstellen, dass diese Schreibvorgänge in Einheiten des physischen Sektors ausgeführt werden.

Um zu ermitteln, ob Ihre Anwendung nicht gebufferte I/O-Probleme hat, überprüfen Sie, ob Sie das FILE_FLAG_NO_BUFFERING Flag im Parameter dwFlagsAndAttributes enthalten, wenn Sie die CreateFile-Funktion aufrufen.

Wenn Sie derzeit die Schreibvorgänge an die Sektorgröße ausrichten, ist diese Sektorgröße wahrscheinlich nur die logische Sektorgröße, da die meisten vorhandenen APIs, die die Branchengröße der Medien abfragen, wirklich nur die Adressierungseinheit abfragen – d. h. die logische Sektorgröße. Die Sektorgröße hier ist die physische Sektorgröße, die die tatsächliche Einheit der Atomitä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

So wird's angezeigt, wie Sie die Größe des physischen Sektors abfragen

Microsoft hat ein Codebeispiel für MSDN-Details bereitgestellt, 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 größe des physischen Sektors des Volumens abrufen, sie sollten jedoch eine grundlegende Sanity-Überprüfung auf die gemeldete physische Sektorgröße durchführen, bevor sie verwendet wird, da festgestellt wurde, dass einige Treiber möglicherweise keine korrekt formatierten Daten zurückgeben:

  • Stellen Sie sicher, dass die gemeldete physische Sektorgröße = die gemeldete logische Sektorgröße ist >. Wenn dies nicht der Grund ist, sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Stellen Sie sicher, dass die gemeldete größe des physischen Sektors eine Leistung von zwei ist. Wenn dies nicht der Grund ist, sollte Ihre Anwendung eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Wenn die Größe des physischen Sektors zwischen 512 Bytes und 4 KB ein Leistungswert von zwei Werten ist, sollten Sie die Verwendung einer physischen Sektorgröße in Betracht ziehen, die auf die gemeldete logische Sektorgröße gerundet ist.
  • Wenn die Größe des physischen Sektors einen Wert mit einer Leistung von zwei Größen größer als 4 KB ist, sollten Sie die Fähigkeit Ihrer Anwendung auswerten, dieses Szenario zu behandeln, bevor Sie diesen Wert verwenden. Andernfalls sollten Sie die Verwendung einer physischen Sektorgröße in Betracht ziehen, die auf 4 KB gerundet ist.

Die Verwendung dieser IOCTL zum Abrufen der größe des physischen Sektors 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 wie oben beschrieben schreiben.

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

  • Kein Dateihandle ausgestellt werden kann (das IOCTL muss an einen Volume Handle ausgestellt werden).

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

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

Anwendungen mit einem Datenspeicher verfügen in der Regel über eine Form von Commitdatensatz, 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 auf eine Sektorgröße gepolstert. Bei einem Datenträger mit einer größeren physischen Sektorgröße muss die Anwendung nach der physischen Sektorgröße abfragen, wie im vorherigen Abschnitt gezeigt, und stellen Sie sicher, dass jeder Commitdatensatz auf diese Größe gepolstert ist. Dies verhindert nicht nur den Read-Modify-Write-Zyklus, es hilft sicherzustellen, dass bei Verlust eines physischen Sektors nur ein Commit-Datensatz verloren geht.

Protokolldateien werden in nicht ausgerichtete Abschnitte geschrieben.

Unbuffered I/O wird in der Regel beim Aktualisieren oder Anfügen an eine Protokolldatei verwendet. Es gibt verschiedene Möglichkeiten, um sicherzustellen, dass diese Updates ordnungsgemäß ausgerichtet sind:

  • Interne Pufferprotokollaktualisierungen der gemeldeten physischen Sektorgröße des Betriebsmediums und Das Problemprotokoll schreibt nur, wenn eine physische Sektoreinheit voll ist.
  • Verwenden von gepufferten E/A

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

Einige Anwendungen mit Standarddateiformaten (z. B. VHD 1.0) haben diese Dateien möglicherweise hartcodiert, um eine Größe von 512-Byte-Sektoren zu übernehmen. Daher würden Updates und Schreibvorgänge in diese Datei zu einem Lese-Änderungs-Schreibzyklus auf dem Gerät führen – was potenziell zu Leistungs- und Ausfallsicherheitsbedenken 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 Sie Pufferung, um sicherzustellen, dass Schreibvorgänge in Einheiten der physischen Sektorgröße ausgeführt werden.
  • Implementieren eines internen Read-Modify-Write-Elements, das sicherstellen kann, dass Updates in Einheiten der gemeldeten physischen Sektorgröße ausgeführt werden
  • Wenn möglich, zeichnet die Pad-Aufzeichnung in einem physischen Sektor auf, so dass der Abstand 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 hostt, ä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 ein unerwartetes Ereignis für viele Anwendungen sein und kann möglicherweise dazu führen, dass einige Anwendungen sogar nicht erneut initialisiert werden.

Dies ist nicht das einfachste Szenario zur Unterstützung 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 negativ durch die Verwendung von 512e-Medien beeinflusst werden.

4 KB Native Medien

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

  • Die Größen des logischen und physischen Sektors sind beide 4 KB
  • Da keine Emulationsebene vorhanden ist, sind nicht ausgerichtete Schreibvorgänge durch den Speicher fehlgeschlagen.
  • Kein ausgeblendeter Ausfallsicherheitstreffer – Anwendungen funktionieren entweder oder sie funktionieren nicht

Obwohl Microsoft derzeit unterstützung für diese Medientypen in einer zukünftigen Version von Windows untersucht und bei Bedarf einen KB-Artikel ausgibt, sollten Anwendungsentwickler die Unterstützung für diese Medientypen vorab berücksichtigen.

Schließen

In diesem Artikel haben wir die Auswirkungen erörtert, die große Medien in großem Sektor mit vielen gängigen Bereitstellungsszenarien einführen. Wir haben die Leistungs- und Ausfallsicherheit von Read-Modify-Write 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 letztendlich den Endbenutzer betrifft. Die Speicherindustrie wechselt schnell zu Medien mit größeren Branchengrößen, und sehr bald können Kunden Datenträger mit herkömmlichen 512-Byte-Branchengrößen nicht kaufen.

Dies ist ein lebendiges Dokument und ist als Hilfe für Entwickler gedacht, um diesen Übergang zu verstehen. Sie sollten eine Unterhaltung mit Ihren jeweiligen Organisationen beginnen, mit Kunden, IT-Experten und Ihren Hardwareanbietern zu sprechen, um über den übergang des großen Sektors zu sprechen und wie es sich auf die Szenarien auswirkt, die Für Sie wichtig sind.