Advanced Format (4K)-Datenträgerkompatibilitätsupdate

Plattformen

Clients Windows XP, Windows Vista, Windows 7, Windows 7 SP1, Windows 8
Server Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016

Beschreibung

Dieser Artikel ist eine aktualisierte Version des Artikels mit dem Titel „512-Byte Emulation (512e)-Datenträgerkompatibilitätsupdate“, der für Windows 7 SP1 und Windows Server 2008 R2 SP1 veröffentlicht wurde. Dieses Update enthält viele neue Informationen, von denen einige nur für Windows 8 und Windows Server 2012 gelten.

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 Microsoft mit Windows 7 und Windows 8 eingeführt hat, um Entwickler*innen die Unterstützung dieser Gerätetypen zu ermöglichen. Während dieses Thema Richtlinien zur Verbesserung der Kompatibilität mit Advanced Format-Datenträgern enthält, gelten die Informationen im Allgemeinen für alle Systeme mit Advanced Format-Datenträgern unter Windows Vista, Windows 7 und Windows 8.

Zusammenfassung der neuen Features im Zusammenhang mit großen Sektoren

In der folgenden Liste werden die neuen Features zusammengefasst, die als Teil von Windows 8 und Windows Server 2012 bereitgestellt werden, um den Kunden- und Entwicklerkomfort mit großen Datenträgern zu verbessern. Ausführlichere Beschreibung für jedes Element folgen.

• Baut auf der Windows 7 SP1-Unterstützung für 4K-Datenträger mit Emulation (512e) auf und bietet vollständige In-Box-Unterstützung für Datenträger mit 4 K-Sektorgröße ohne Emulation (4 K Native). Zu den unterstützten Apps und Szenarien gehören:
  • Möglichkeit zum Installieren und Starten von Windows auf einem 4 K-Sektor-Datenträger ohne Emulation (4 K Native Disk)
  • VHD- und das neue VHDX-Dateiformat
  • Vollständige HyperV-Unterstützung
  • Windows-Sicherung
  • Vollständige Unterstützung im NT-Dateisystem (NTFS)
  • Vollständige Unterstützung mit dem neuen Storage Spaces and Pools (SSP)
  • Vollständige Unterstützung mit Windows Defender
• Stellt eine neue API zum Abfragen der Größe des physischen Sektors bereit (FileFsSectorSizeInformation):
  • Verfügbar für Netzwerk-Datenträger
  • Kann für beliebige Dateihandles ausgegeben werden
  • Verfügbar für nicht privilegierte Apps
  • Benutzerfreundlicheres Nutzungsmodell
• Enthält ein erweitertes Fsutil-Befehlszeilenprogramm, um die Größe des Datenträgers für den logischen und den physischen Sektor mit Ausrichtungsinformationen abzufragen (die Standardversion des Hilfsprogramms ohne Ausrichtungsinformationen ist für Windows 7 mit Microsoft KB 982018 und Windows Server 2008 R2 mit Microsoft KB 982018 verfügbar)

Einführung in Advanced Format (4 K)-Datenträger

Eines der Probleme bei der Einführung dieser Änderung des Medienformats ist die Gefahr, dass damit Kompatibilitätsprobleme mit bestehender Software und Hardware eingeführt werden. Als temporäre Kompatibilitätslösung führt die Speicherbranche zunächst Datenträger ein, die einen regulären 512-Byte-Sektor-Datenträger emulieren, aber Informationen über die tatsächliche Sektorgröße über standardmäßige ATA- und SCSI-Befehle zur Verfügung stellen. Aufgrund dieser Emulation gibt es im Wesentlichen 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 aktuellen Windows-APIs, z. B. IOCTL_DISK_GET_DRIVE_GEOMETRY, geben die Größe des logischen Sektors zurück, aber die Größe des physischen Sektors kann über den IOCTL_STORAGE_QUERY_PROPERTY-Steuerelementcode mit den relevanten Informationen im Feld BytesPerPhysicalSector in der STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR-Struktur abgerufen werden. Dies wird später in diesem Artikel noch genauer behandelt.

Erste Typen von Medien mit großen Sektoren

Die Speicherbranche setzt sich schnell für den Übergang zu diesem neuen Advanced Format-Speichertyp für Medien mit einer physischen Sektorgröße von 4 KB ein. 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. Das allgemeine Problem mit diesem neuen Medientyp besteht darin, dass die meisten Apps und Betriebssysteme E/As nicht nach der Größe des physischen Sektors abfragen und daran ausrichten, was zu unerwarteten Fehlschlägen von E/A-Vorgängen führen kann.
512-Byte-Emulation (512e): Diese Medien verfügen über eine Emulationsebene, wie im vorherigen Abschnitt beschrieben, und machen 512 Byte als logische Sektorgröße (ähnlich wie ein normaler Datenträger heute) verfügbar, stellen aber Informationen zur Größe des physischen Sektors (4 KB) zur Verfügung. Das allgemeine Problem mit dieser neuen Medienart besteht darin, dass die Mehrzahl der App- und Betriebssysteme das Vorhandensein der Größe des physischen Sektors nicht versteht, was zu einer Reihe von Problemen führen kann, wie unten beschrieben.
Allgemeine Windows-Unterstützung für Medien mit großen Sektoren

Diese Tabelle dokumentiert die offizielle Microsoft-Supportrichtlinie für verschiedene Medien und die daraus resultierenden Sektorgrößen. Nähere Einzelheiten finden Sie in diesem KB-Artikel.

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, die wir im folgenden Beispiel durchgehen.

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

Wie oben dargestellt, beinhaltet dieser Prozess einige Aktionen des Speichergerät, die zu Leistungsverlusten führen können. Um dies zu vermeiden, müssen Apps für folgende Aktionen aktualisiert werden:

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

Obwohl dies anfänglich nur wie ein Leistungsproblem aussehen mag, kann es schwerwiegendere Probleme geben. Dies wird im nächsten Abschnitt erläutert.

Resilienz: die versteckten Kosten von Read-Modify-Write

Bei der Resilienz geht es um die Fähigkeit einer App, den 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.

Richtiges Vorgehen (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. Apps sollten sich daher nicht auf diese Gegenmaßnahmen als langfristige Lösungen verlassen. Darüber hinaus gibt es keine Garantie dafür, dass alle Datenträgerklassen diese Gegenmaßnahmen implementiert haben, und auch nicht dafür, dass diese Maßnahmen korrekt und gut gestaltet sind.

Die Lösung hierfür ist keine Gegenmaßnahme für den Datenträger, sondern die Gestaltung von Apps, so dass diese das Richtige tun, um diese Art von Medien zu unterstützen. In diesem Abschnitt werden allgemeine Szenarien erläutert, in denen Apps Probleme mit großen Datenträgern haben können; dazu wird eine Möglichkeit zur Untersuchung vorgeschlagen, um jedes Problem zu testen und 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.) Verwenden Sie stattdessen die IVdsCreatePartitionEx::CreatePartitionEx- oder IVdsAdvancedDisk::CreatePartition-APIs, die den angegebenen Ausrichtungsparameter für apps verwenden, die Partitionen erstellen müssen.

Die beste Methode, um sicherzustellen, dass die Ausrichtung korrekt ist, besteht darin, sie beim anfänglichen Erstellen der Partition korrekt einzurichten. Andernfalls muss Ihre App beim Ausführen von Schreibvorgängen oder bei der Initialisierung die Ausrichtung berücksichtigen, was ein sehr komplexer Prozess sein kann.

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

Das einfachste Problem besteht darin, dass nicht gepufferte Schreibvorgänge nicht an der gemeldeten physischen Sektorgröße des Speichermediums ausgerichtet sind. 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 Apps mit einem Datenspeicher führen jedoch nicht-gepufferte Schreibvorgänge durch und müssen daher sicherstellen, dass diese Schreibvorgänge in Einheiten der Größe des physischen Sektors ausgeführt werden.

Einige Beispiele für Szenarien, in denen die resultierende App-E/A nicht ausgerichtet ist:

Commit-Datensätze werden zu 512 Byte-Sektoren aufgefüllt: Apps mit einem Datenspeicher verfügen in der Regel über eine Form von Commit-Datensatz, die Informationen zu Metadatenänderungen 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 App die Größe des physischen Sektors abfragen, wie im vorherigen Abschnitt dargestellt, und sicherstellen, dass jeder Commit-Datensatz auf diese Größe aufgefüllt wird. Bei einem 4K-Datenträger wird dadurch sichergestellt, dass E/As nicht fehlschlagen. Bei einem 512e-Datenträger wird dadurch nicht nur der Read-Modify-Write-Zyklus vermieden, sondern auch sichergestellt, dass bei Verlust eines physischen Sektors nur ein Commit-Datensatz verloren geht.
Protokolldateien werden in nicht ausgerichteten Chunks geschrieben: Nicht gepufferte E/A-Vorgänge werden in der Regel beim Aktualisieren oder Anfügen an eine Protokolldatei verwendet. Apps können entweder zu gepuffertem E/A wechseln oder die Protokollaktualisierungen in Größeneinheiten des physischen Sektors intern puffern, um fehlerhafte E/A-Vorgänge das Auslösen von Read-Modify-Write zu vermeiden.
Um festzustellen, ob Ihre App nicht-gepufferte E/A ausgibt, stellen Sie sicher, dass Sie das FILE_FLAG_NO_BUFFERING-Flag in den Parameter dwFlagsAndAttributes einschließen, wenn Sie die CreateFile-Funktion aufrufen.

Wenn Sie die Schreibvorgänge derzeit an der Sektorgröße ausrichten, ist diese Sektorgröße wahrscheinlich nur die logische Sektorgröße, da die meisten vorhandenen APIs, die die Sektorgröße der Medien abfragen, nur die Einheit der Adressierung 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 können Sie die Größe des physischen Sektors abfragen:

Bevorzugte Methode für Windows 8

Mit Windows 8 hat Microsoft eine neue API eingeführt, mit der Entwickler die 4K-Unterstützung einfach in ihre Apps integrieren können. Diese neue API unterstützt eine noch größere Anzahl von Szenarien als die weiter unten beschriebene ältere Methode für Windows Vista und Windows 7. Diese API ermöglicht diese Aufrufszenarien:

• Aufrufen von einer nicht privilegierten App
• Aufrufen eines beliebigen gültigen Dateihandles
• Aufrufen eines Dateihandles auf einem Remote-Datenträger über SMB2
• Vereinfachtes Programmiermodell

Die API ist in Form einer neuen Infoklasse, FileFsSectorSizeInformation, mit zugeordneter Struktur FILE_FS_SECTOR_SIZE_INFORMATION definiert, wie folgt definiert:

typedef struct _FILE_FS_SECTOR_SIZE_INFORMATION {  
    ULONG LogicalBytesPerSector;  
    ULONG PhysicalBytesPerSectorForAtomicity;  
    ULONG PhysicalBytesPerSectorForPerformance;  
    ULONG FileSystemEffectivePhysicalBytesPerSectorForAtomicity;  
    ULONG Flags;  
    ULONG ByteOffsetForSectorAlignment;  
    ULONG ByteOffsetForPartitionAlignment;  
} FILE_FS_SECTOR_SIZE_INFORMATION, *PFILE_FS_SECTOR_SIZE_INFORMATION;

Ältere Methode für Windows 7 und Windows Vista

Windows Vista und Windows Server 2008 haben APIs eingeführt, um die physische Sektorgröße des angefügten Speichergeräts für AHCI-basierte Speichercontroller abzufragen. Mit Windows 7 und Windows Server 2008 R2 wird diese Unterstützung ab SP1 (oder Microsoft Knowledge Base 982018) auf Storport-basierte Speichercontroller erweitert. Ein Codebeispiel, das zeigt, wie eine App die Größe des physischen Sektors des Datenträgers abfragen kann, finden Sie unter STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR-STRUKTUR.

Im obigen Codebeispiel können Sie zwar die Größe des physischen Sektors des Datenträgers abrufen, doch sollten Sie vor der Verwendung einige grundlegende Überprüfungen der gemeldeten physischen Sektorgröße durchführen, da festgestellt wurde, dass 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 App eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
• Stellen Sie sicher, dass die gemeldete physische Sektorgröße eine Potenz von zwei ist; wenn dies nicht der Fall ist, sollte Ihre App 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 physische Sektorgröße eine Potenz von zwei Werten über 4 KB ist, sollten Sie die Fähigkeit Ihrer App prüfen, mit diesem Szenario umzugehen, bevor Sie diesen Wert verwenden. andernfalls sollten Sie die Verwendung einer physischen Sektorgröße in Betracht ziehen, die auf 4 KB aufgerundet wurde.

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

• Erfordert höhere Berechtigungen; wenn Ihre App nicht mit Berechtigungen ausgeführt wird, müssen Sie möglicherweise eine Windows Service-Anwendung schreiben, wie oben erwähnt.
• Unterstützt keine SMB-Datenträger; möglicherweise müssen Sie auch eine Windows Service-Anwendung 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)

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

Einige Apps mit Standarddateiformaten (z. B. VHD 1.0) haben diese Dateien möglicherweise hartcodiert, um eine Größe mit 512 Byte-Sektoren anzunehmen. Daher führen Aktualisierungen und Schreibvorgänge in diese Datei zu einem Read-Modify-Write-Zyklus auf dem Gerät, der möglicherweise zu Leistungs- und Resilienzproblemen für Ihre Kunden führt. Es gibt jedoch Möglichkeiten für eine App, 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
• Erwägen der Neugestaltung einer Version der App-Datenstruktur mit Unterstützung für größere Sektoren

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 ein unerwartetes Ereignis für viele Apps sein und dazu führen, dass einige Apps 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 4K nativen oder 512e-Medien nicht beeinträchtigt werden.

Wie Benutzer die Größe des logischen und physischen Sektors eines Datenträgers abrufen können

In-box mit Windows ist eine Möglichkeit zur Anzeige der Sektorgröße eines Datenträgers. Versionen von Windows mit unterstütztem fsutil sind:

• Windows 8
• Windows Server 2012
• Windows 7 SP1 mit Microsoft KB 982018
• Windows 7 mit Microsoft KB 982018
• Windows Server 2008 R2 SP1 mit Microsoft KB 982018 (v3)
• Windows Server 2008 R2 mit Microsoft KB 982018 (v3)
• Windows Vista mit Microsoft KB 2553708
• Windows Server 2008 mit Microsoft KB 2553708

Rufen Sie zum Abrufen der Sektorgröße das Hilfsprogramm wie folgt in einer Eingabeaufforderung mit erhöhten Rechten auf:

fsutil fsinfo ntfsinfo <drive letter>

Ein 4K-Sektor-Datenträger mit 512 Byte-Emulation weist das Feld „Byte pro Sektor“ mit 512 und das Feld „Byte pro physischer Sektor“ mit 4096 auf, wie folgt:

Ein 4K-nativer Datenträger weist die Felder „Byte pro Sektor“ und „Byte pro physischer Sektor“ jeweils mit 4096 auf, wie folgt:

Ressourcen

• Allgemeine Aussage zum Windows Support
• Microsoft KB 982018
• Hotfix für Windows 7 und Windows Server 2008 R2
• Aussage zur HyperV-Unterstützung
• Allgemeine Informationen zum Steuercode IOCTL_STORAGE_QUERY_PROPERTY
• Steuercode IOCTL_STORAGE_QUERY_PROPERTY
• Allgemeine Informationen zur Struktur STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR
• Beschreibung der Standardterminologie für die Beschreibung von Microsoft-Softwareupdates
• WDK-Beispielcode mit Details zum Extrahieren der gemeldeten Speicherzugriff-Ausrichtungsinformationen aus der STORAGE_ACCESS_ALIGNMENT_DESCRIPTOR-Struktur beim Aufrufen des Steuercodes IOCTL_STORAGE_QUERY_PROPERTY
• Allgemeine Informationen zu ImageX-Befehlszeilenoptionen
• Anforderungen des Intel-Chipsatztreibers zur Unterstützung von Datenträgern mit 4-KB-Sektoren: