Update für die Datenträgerkompatibilität im erweiterten Format (4K)

  • Artikel

Plattformen

Kunden 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) Disk Compatibility Update, das 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 Arealdichten nehmen jährlich zu, und mit dem jüngsten Aufkommen von 3-TB-Datenträgern werden die Fehlerkorrekturmechanismen, die zur Bewältigung des abnehmenden Signal-zu-Rausch-Verhältnisses (SNR) verwendet werden, speicherplatzineffizient; Das heißt, es ist ein erhöhter Mehraufwand erforderlich, um sicherzustellen, dass die Medien verwendbar 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, wie Apps diese Art von Medien unterstützen können, und die Infrastruktur, die Microsoft mit Windows Vista, Windows 7 und Windows 8 eingeführt hat, damit Entwickler diese Gerätetypen unterstützen können. Obwohl das in diesem Thema vorgestellte Material Richtlinien für die 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, auf denen Windows Vista, Windows 7 und Windows 8 ausgeführt werden.

Zusammenfassung der neuen Features im Zusammenhang mit großen Sektoren

Die folgende Liste fasst die neuen Features zusammen, die im Rahmen von Windows 8 und Windows Server 2012 bereitgestellt werden, um die Kunden- und Entwicklererfahrung mit datenträgern großer Sektoren zu verbessern. Ausführlichere Beschreibungen 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 Posteingangsunterstützung für Datenträger mit 4K-Sektorgröße ohne Emulation (4K Native). Zu den unterstützten Apps und Szenarien gehören:
    • Möglichkeit zum Installieren und Starten von Windows auf einem 4K-Sektordatenträger ohne Emulation (nativer 4K-Datenträger)
    • VHD und neues VHDX-Dateiformat
    • Vollständige HyperV-Unterstützung
    • Windows-Sicherung
    • Vollständige Unterstützung im NT-Dateisystem (NTFS)
    • Vollständige Unterstützung mit neuen Speicherplätze und 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 Netzwerkvolumes
    • Kann für jedes Dateihandle ausgegeben werden.
    • Verfügbar für nicht privilegierte Apps
    • Freundlicheres Nutzungsmodell
  • Enthält ein erweitertes Fsutil-Befehlszeilenprogramm zum Abfragen der logischen und physischen Sektorgröße des Volumes mit Ausrichtungsinformationen (Basisversion 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 4K-Datenträger (Advanced Format)

Eines der Probleme bei der Einführung dieser Änderung des Medienformats ist das Potenzial, Kompatibilitätsprobleme mit vorhandener Software und Hardware zu verursachen. Als temporäre Kompatibilitätslö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 zur tatsächlichen Sektorgröße verfügbar machen. Als Ergebnis dieser Emulation gibt es im Wesentlichen 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 für das Gerät in einem einzigen Vorgang abgeschlossen 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 von Medien im großen Sektor

Die Speicherbranche nimmt die Bemühungen zur Umstellung auf diesen neuen Advanced Format-Speichertyp für Medien mit einer Physischen Sektorgröße von 4 KB schnell auf. Zwei Arten von Medien werden auf den Markt gebracht:

4 KB nativ: Dieses Medium verfügt über keine Emulationsebene und macht direkt 4 KB als logische und physische Sektorgröße verfügbar. Das Allgemeine Problem bei diesem neuen Medientyp besteht darin, dass die Mehrheit der Apps und Betriebssysteme die E/A-Größe nicht abfragen und daran ausrichten, was zu unerwartet fehlerhaften E/A-Vorgängen führen kann.
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 regulären Datenträger heute), stellt jedoch die Informationen zur größe des physischen Sektors (4 KB) zur Verfügung. Das Allgemeine Problem bei diesem neuen Medientyp besteht darin, dass die Mehrheit der App- 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.
Allgemeine Windows-Unterstützung für große Sektormedien

Diese Tabelle dokumentiert die offizielle Microsoft-Supportrichtlinie für verschiedene Medien und die daraus resultierenden gemeldeten Branchengrößen. Weitere Informationen finden Sie in diesem KB-Artikel .

Allgemeine Namen Gemeldete Größe des logischen Sektors Gemeldete Größe des physischen Sektors Windows-Version mit Support
512 Byte Native, 512n 512 Bytes 512 Bytes Alle Windows-Versionen
Erweitertes Format, 512e, AF, 512-Byte-Emulation 512 Bytes 4 KB Windows Vista mit MS KB-2553708
Windows Server 2008* mit MS KB-2553708
Windows 7 mit MS KB-982018
Windows Server 2008 R2* mit MS KB-982018
Alle Windows-Versionen ab Windows 7 SP1.
Alle Serverversionen von Server 2008 R2 SP1 und höher.

*Mit Ausnahme von Hyper-V. Weitere Informationen finden Sie im Abschnitt "Anwendungsunterstützungsanforderungen für Großsektorlaufwerke" .
Advanced Format, AF, 4K Native, 4Kn 4 KB 4 KB Alle Windows-Versionen ab Windows 8
Alle Serverversionen von Windows Server 2012 und darüber hinaus
Sonstiges Nicht 4 KB oder 512 Bytes Nicht 4 KB oder 512 Bytes Nicht unterstützt

Hinweis

Windows XP, Windows Server 2003 und Windows Server 2003 R2 unterstützen 512e- oder 4Kn-Medien zwar nicht. Zwar kann das System gestartet werden und minimal betrieben werden, es kann jedoch unbekannte Szenarien mit Funktionalitätsproblemen, Datenverlust oder einer unteroptimalen Leistung geben. Daher warnt Microsoft dringend davor, 512e-Medien mit Windows XP oder anderen Produkten zu verwenden, die auf der Windows XP-Codebasis basieren (z. B. Windows Home Server 1.0, Windows Server 2003, Windows Server 2003 R2, Windows XP 64-Bit Edition, Windows XP Embedded, Windows Small Business Server 2003 und Windows Small Business Server 2003 R2).

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 wir im folgenden Beispiel durchlaufen.

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

Schritte für ein Speichergerät zum Abschließen eines Schreibvorgangs

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 Apps aktualisiert werden:

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

Obwohl dies zunächst nur ein Leistungsproblem zu sein scheint, kann es schwerwiegendere Probleme geben. Lassen Sie uns dies im nächsten Abschnitt besprechen.

Resilienz: Die versteckten Kosten für Lese-,Änderungs-/Schreibzugriff

Resilienz spricht von der Fähigkeit einer App, den Zustand zwischen Sitzungen wiederherzustellen. Wir haben gesehen, was für ein 512e-Speichergerät erforderlich ist, um einen 512-Byte-Sektor beim Schreiben des Lese-/Änderungs-Schreibzyklus auszuführen. 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 worden sein. 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 Apps 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 die 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 App, die einen Lese-/Änderungs-Schreibzyklus verursacht, möglicherweise dazu führen kann, dass Ihre Daten verloren gehen, auch wenn Ihre App nicht ausgeführt wird! Dies liegt einfach daran, dass sich Ihre Daten und die Daten der anderen App innerhalb desselben physischen Sektors befinden können.

Vor diesem Hintergrund ist es wichtig, dass die App-Software 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.

Das Richtige tun (Vermeiden von Lese-,Änderungs-Schreibvorgängen)

Während einige Speicheranbieter möglicherweise einige Stufen der Entschärfung innerhalb bestimmter 512e-Speichergeräte einführen, um die Leistungs- und Resilienzprobleme des Lese-/Änderungs-Schreibzyklus zu erleichtern, gibt es nur so viel, was die Entschärfung in Bezug auf die Workload bewältigen kann. Daher sollten Sich Apps nicht auf diese Entschärfung als langfristige Lösung verlassen. Darüber hinaus gibt es keine Garantie, dass für alle Datenträgerklassen diese Entschärfung eingerichtet wird, und es gibt auch keine Garantie, dass die Risikominderung gut konzipiert ist.

Die Lösung hierfür besteht nicht in der Risikominderung, sondern darin, Apps so zu entwerfen, dass sie die richtigen Aktionen ausführen, um diese Art von Medien zu unterstützen. In diesem Abschnitt werden häufige Szenarien erläutert, in denen Apps möglicherweise Probleme mit großen Sektordatenträgern haben, 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 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, sondern den Standardausrichtungswert für das Betriebssystem (Vor Windows Vista SP1 wird 63 Byte verwendet, und nach Windows Vista SP1 werden die oben angegebenen Standardwerte verwendet). Verwenden Sie stattdessen die APIs IVdsCreatePartitionEx::CreatePartitionEx oder IVdsAdvancedDisk::CreatePartition, die den angegebenen Ausrichtungsparameter für die Apps verwenden, die Partitionen erstellen müssen.

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 App die Ausrichtung beim Ausführen von Schreibvorgängen oder bei der Initialisierung berücksichtigen, was ein sehr komplexer Prozess sein kann.

Problem 2: Ungepufferte 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 der ersten Generation großer Sektormedien entspricht. Die meisten Apps 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.

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

Commitdatensätze sind auf 512-Byte-Sektoren aufgefüllt: Apps 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 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 gezeigt, und sicherstellen, dass jeder Commitdatensatz auf diese Größe aufgefüllt wird. Bei einem 4K-Datenträger wird dadurch sichergestellt, dass keine E/A-Fehler auftreten. Bei einem 512e-Datenträger wird dadurch nicht nur der Lese-/Änderungs-Schreibzyklus vermieden, er trägt auch dazu bei, dass nur ein Commitdatensatz verloren geht, wenn ein physischer Sektor verloren geht.
Protokolldateien werden in nicht ausgerichtete Blöcke geschrieben: Ungepufferte E/A-Vorgänge werden in der Regel beim Aktualisieren oder Anfügen an eine Protokolldatei verwendet. Apps können entweder zu gepufferten E/A-Vorgängen wechseln oder die Protokollupdates intern auf Einheiten der physischen Sektorgröße puffern, um fehlerhafte E/A-Vorgänge oder das Auslösen eines Lese-/Änderungs-Schreibvorgangs zu vermeiden.
Um festzustellen, ob Ihre App ungepufferte E/A-Vorgänge ausgibt, müssen Sie beim Aufrufen der CreateFile-Funktion das FILE_FLAG_NO_BUFFERING-Flag in den dwFlagsAndAttributes-Parameter einschließen.

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, 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

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 den 4K-Support problemlos in ihre Apps integrieren können. Diese neue API unterstützt noch mehr Szenarien als die unten beschriebene Legacymethode für Windows Vista und Windows 7. Diese API ermöglicht die folgenden Aufrufszenarien:

  • Aufrufen von einer nicht privilegierten App
  • Aufrufen eines gültigen Dateihandles
  • Aufrufen eines Dateihandles auf einem Remotevolume über SMB2
  • Vereinfachtes Programmiermodell

Die API hat die Form einer neuen Infoklasse, FileFsSectorSizeInformation, mit der zugeordneten Struktur FILE_FS_SECTOR_SIZE_INFORMATION, die wie folgt definiert ist:

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;

Legacymethode 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. Microsoft hat auf MSDN ein Codebeispiel bereitgestellt, in dem beschrieben wird, wie eine App die physische Sektorgröße des Volumes abfragen kann.

Im obigen Codebeispiel können Sie zwar die größe des physischen Sektors des Volumes abrufen, aber Sie sollten vor der Verwendung eine grundlegende Integritätsprüfung der gemeldeten physischen Sektorgröße durchführen, da festgestellt wurde, dass einige Treiber möglicherweise keine ordnungsgemäß formatierten Daten zurückgeben:

  • Stellen Sie sicher, dass die gemeldete größe des physischen Sektors = die gemeldete logische Sektorgröße ist >. 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 größe des physischen Sektors eine Leistung von zwei beträgt. Andernfalls sollte Ihre App eine physische Sektorgröße verwenden, die der gemeldeten logischen Sektorgröße entspricht.
  • Wenn die größe des physischen Sektors einen Power-of-Two-Wert zwischen 512 Byte und 4 KB aufweist, 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 Power-of-Two-Wert größer als 4 KB ist, sollten Sie die Fähigkeit Ihrer App zur Behandlung dieses Szenarios bewerten, bevor Sie diesen Wert verwenden. Andernfalls sollten Sie die Verwendung einer auf 4 KB abgerundeten physischen Sektorgröße in Betracht ziehen.

Die Verwendung dieser IOCTL zum Abrufen der Größe des physischen Sektors weist mehrere Einschränkungen auf. Sie hat folgende Aufgaben:

  • Erfordert erhöhte Berechtigungen; Wenn Ihre App nicht mit Berechtigungen ausgeführt wird, müssen Sie möglicherweise wie oben erwähnt eine Windows-Dienstanwendung schreiben.
  • Unterstützt keine SMB-Volumes. 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 Dateihandle ausgestellt werden (die IOCTL muss für ein Volumehandle ausgestellt werden)

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

Bei einigen Apps 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 in diese Datei zu einem Lese-/Änderungs-Schreibzyklus auf dem Gerät führen, was zu Leistungs- und Resilienzproblemen für Ihre Kunden führen kann. Es gibt jedoch Möglichkeiten, wie eine App den Betrieb auf diesen Medientyp unterstützen kann, z. B.:

  • Verwenden der Pufferung, um sicherzustellen, dass Schreibvorgänge in Einheiten der größe des physischen Sektors 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 pad in einem physischen Sektor auf, so dass der Abstand als leerer Raum interpretiert wird.
  • Erwägen Sie die Neugestaltung einer Version der App-Datenstruktur mit Unterstützung für größere Sektoren.

Problem 4: Die gemeldete größe des physischen Sektors kann sich zwischen Sitzungen ändern.

Es gibt viele Szenarien, in denen sich die gemeldete größe des physischen Sektors 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 Größe des physischen Sektors kann für viele Apps ein unerwartetes Ereignis sein und möglicherweise dazu führen, dass einige Apps 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 negativ durch die Verwendung nativer 4K- oder 512e-Medien beeinträchtigt werden.

Abrufen der logischen und physischen Sektorgröße für ein Volume durch einen Benutzer

Im Lieferumfang von Windows ist ein Hilfsprogramm zum Anzeigen der Sektorgrößeninformationen für ein Volume. Versionen von Windows mit unterstützter 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 das Hilfsprogramm wie folgt über eine Eingabeaufforderung mit erhöhten Rechten auf, um die Informationen zur Sektorgröße abzurufen:

fsutil fsinfo ntfsinfo <drive letter>

Ein 4K-Sektordatenträger mit 512-Byte-Emulation hat das Feld Bytes pro Sektor auf 512 und das Feld Bytes pro physischem Sektor wie folgt auf 4096 festgelegt:

Bytes pro Sektor und pro physischem Sektor eines 4.000-Sektordatenträgers mit 512-Byte-Emulation

Auf einem nativen 4K-Datenträger sind die Felder Bytes pro Sektor und Bytes pro physischem Sektor wie folgt auf 4096 festgelegt:

Bytes pro Sektor und physischem Sektor eines nativen 4K-Datenträgers

Hinweis

Wenn im Feld Byte pro physischer Sektor nicht unterstützt angezeigt wird, unterstützt der Speichertreiber IOCTL_STORAGE_QUERY_PROPERTY nicht, oder beim Abrufen der Informationen ist ein Fehler aufgetreten.

Ressourcen