Update der Datenträgerkompatibilität im erweiterten Format (4K)
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) 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 aktuellen Aufkommen von 3 TB Datenträgern werden die Fehlerkorrekturmechanismen, die zum Umgang mit dem abnehmenden Signal-Rausch-Verhältnis (Signal-to-Noise-Ratio, SNR) verwendet werden, ineffizient. Das heißt, es ist ein höherer Mehraufwand erforderlich, um sicherzustellen, dass die Medien verwendbar sind. 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 hinsichtlich der 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, und es wird erläutert, welche Möglichkeiten Apps zur Unterstützung dieser Art von Medien haben. Außerdem wird die Infrastruktur erläutert, die Microsoft mit Windows Vista, Windows 7 und Windows 8 eingeführt hat, 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 Datenträgern im erweiterten Format enthält, gelten die Informationen im Allgemeinen für alle Systeme mit Datenträgern im erweiterten Format, die Windows Vista, Windows 7 und Windows 8 ausgeführt werden.
Zusammenfassung der neuen Features im Zusammenhang mit großen Sektoren
In der folgenden Liste werden die neuen Features zusammengefasst, die im Rahmen Windows 8 und Windows Server 2012 bereitgestellt werden, um die Kunden- und Entwicklererfahrung mit großen Sektordatenträgern zu verbessern. Eine ausführlichere Beschreibung der einzelnen Elemente finden Sie hier.
- 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 einer Sektorgröße von 4K ohne Emulation (4K Native). Zu den unterstützten Apps und Szenarien gehören:
- Möglichkeit zum Installieren Windows und Starten von 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 physischen Sektorgröße (FileFsSectorSizeInformation) bereit:
- Verfügbar für Netzwerkvolumes
- Kann für jedes Dateihandle ausgegeben werden
- Verfügbar für nicht privilegierte Apps
- Benutzerfreundlicheres Nutzungsmodell
- Enthält ein erweitertes fsutil-Befehlszeilenprogramm zum Abfragen der logischen und physischen Sektorgröße des Volumes mit Ausrichtungsinformationen (grundlegende Version 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 Datenträger im erweiterten Format (4K)
Eines der Probleme bei der Einführung dieser Änderung im Medienformat besteht darin, dass Kompatibilitätsprobleme mit vorhandener Software und Hardware auftreten können. 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 Informationen zur tatsächlichen Sektorgröße über ATA- und SCSI-Standardbefehle zur Verfügung stellen. Aufgrund dieser Emulation gibt es im Wesentlichen zwei Sektorgrößen:
Logischer Sektor: Die Einheit, die für die Adressierung logischer Blöcke 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 Einheit für atomischen Schreibvorgang.
Die meisten aktuellen Windows-APIs, z. B. IOCTL _ DISK _ GET DRIVE _ _ GEOMETRY, geben die größe des logischen Sektor zurück. Die physische Sektorgröße kann jedoch über den IOCTL _ STORAGE QUERY _ PROPERTY-Steuerungscode _ abgerufen werden, wobei die relevanten Informationen im Feld BytesPerPhysicalSector in der _ _ _ DESCRIPTOR-Struktur storage access alignment enthalten sind. Dies wird weiter unten in diesem Artikel ausführlicher erläutert.
Anfängliche Typen großer Sektormedien
Die Speicherbranche setzt die Umstellung auf diesen neuen Speichertyp im erweiterten Format für Medien mit einer physischen Sektorgröße von 4 KB schnell fort. Zwei Medientypen werden auf dem Markt veröffentlicht:
4 KB nativ: Dieses Medium verfügt über keine Emulationsebene und macht 4 KB direkt als logische und physische Sektorgröße verfügbar. Das Gesamtproblem bei diesem neuen Medientyp besteht darin, dass die Meisten Apps und Betriebssysteme keine E/A-Abfragen durchführen und die E/A-Daten nicht an der physischen Sektorgröße ausrichten, was zu unerwarteten E/A-Aussichten führen kann.
512-Byte-Emulation (512e): Dieses Medium verfügt über eine Emulationsebene, wie im vorherigen Abschnitt erläutert, und macht 512 Bytes als logische Sektorgröße verfügbar (ähnlich wie ein regulärer Datenträger heute), stellt aber informationen zur physischen Sektorgröße (4 KB) zur Verfügung. Das Allgemeine Problem bei diesem neuen Medientyp besteht darin, dass die Mehrheit der App- und Betriebssysteme das Vorhandensein der physischen Sektorgröße nicht versteht. Dies kann zu einer Reihe von Problemen führen, wie im Folgenden erläutert wird.
Allgemeine Windows-Unterstützung für große Sektormedien
In dieser Tabelle werden die offizielle Microsoft-Supportrichtlinie für verschiedene Medien und die daraus resultierenden gemeldeten Sektorgrößen dokumentiert. Weitere Informationen finden Sie in diesem KB-Artikel.
| Allgemeine Namen | Gemeldete Größe des logischen Sektor | Gemeldete Größe des physischen Sektor | Windows Version mit Support |
|---|---|---|---|
| 512 Byte nativ, 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 * w/MS KB 2553708 Windows 7 w/MS KB 982018 Windows Server 2008 R2* w/MS KB 982018 Alle Windows Versionen von Windows 7 SP1 und höher. Alle Serverversionen ab Server 2008 R2 SP1. *Mit Ausnahme von Hyper-V. Weitere Informationen finden Sie im Abschnitt "Anforderungen an die Anwendungsunterstützung für Große Sektorlaufwerke". |
| Advance Format, AF, 4K Native, 4Kn | 4 KB | 4 KB | Alle Windows Versionen von Windows 8 und darüber hinaus Alle Serverversionen von Windows Server 2012 und höher |
| Sonstiges | Nicht 4 KB oder 512 Bytes | Nicht 4 KB oder 512 Bytes | Nicht unterstützt |
Hinweis
In der obigen Tabelle werden 512e- oder 4Kn-Medien von Windows XP, Windows Server 2003 und Windows Server 2003 R2 nicht unterstützt. Obwohl das System möglicherweise gestartet wird und minimal betrieben werden kann, kann es unbekannte Szenarien mit Funktionalitätsproblemen, Datenverlust oder suboptimaler 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 sind für Schreibvorgänge, die nicht auf dieser Einheitenebene ausgeführt werden, zusätzliche Schritte erforderlich, die im folgenden Beispiel erläutert werden.
In diesem Szenario muss eine App den Inhalt eines Datastor-Datensatzes aktualisieren, der sich in einem logischen 512-Byte-Sektor befindet. Dieses Diagramm veranschaulicht die Schritte, die für das Speichergerät erforderlich sind, um den Schreibvorgang abzuschließen:

Wie oben gezeigt, umfasst dieser Prozess einige Arbeitsschritte des Speichergeräts, die zu Leistungseinbußen führen können. Um diese zusätzliche Arbeit zu vermeiden, müssen Apps aktualisiert werden auf:
- Abfrage der physischen Sektorgröße
- Stellen Sie sicher, dass Schreibvorgänge an der gemeldeten physischen Sektorgröße ausgerichtet sind.
Obwohl dies anfänglich nur ein Leistungsproblem zu sein scheint, kann es zu einem schwerwiegenderen Problem kommen. Dies wird im nächsten Abschnitt erläutert.
Resilienz: die verborgenen 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 zum Schreiben des Lese-/Änderungs-Schreibzyklus durchzuführen. 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 partiellen Ü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).
- Die meisten Apps mit einem Datenspeicher sind zwar so konzipiert, dass sie nach Medienfehlern wiederhergestellt werden können. Der Verlust von acht Sektoren oder eine andere Möglichkeit, der Verlust von acht Commitdatensätzen, kann es möglicherweise unmöglich machen, dass der Datenspeicher ordnungsgemäß wiederhergestellt wird. 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 das Ausführen 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 im selben physischen Sektor befinden könnten.
Vor diesem Hintergrund ist es wichtig, dass die App-Software alle annahmen im Code neu auswertet und sich der Unterscheidung der logischen und physischen Sektorgröße sowie einigen interessanten Kundenszenarien bewusst ist, die weiter oben in diesem Artikel erläutert werden.
Das Richtige tun (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 Apps nicht auf diese Entschärfung als langfristige Lösung verlassen. Darüber hinaus gibt es keine Garantie dafür, dass diese Entschärfung für alle Klassen von Datenträgern vorhanden ist, und es gibt auch keine Garantie dafür, dass die Entschärfung gut konzipiert ist.
Die Lösung dafür besteht nicht in der Laufwerkminderung, sondern im Entwerfen von Apps, um die richtigen Maßnahmen zur Unterstützung dieser Art von Medien zu finden. In diesem Abschnitt werden häufige Szenarien erläutert, in denen Apps 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 (für Datenträger 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 beim Erstellen eines neuen Volumes nicht den angegebenen Ausrichtungsparameter, sondern den Standardwert für die Ausrichtung für das Betriebssystem (Pre-Windows Vista SP1 verwendet 63 Bytes, und nach Windows Vista SP1 werden die oben genannten Standardwerte verwendet). Verwenden Sie stattdessen die IVdsCreatePartitionEx::CreatePartitionEx- oder IVdsAdvancedDisk::CreatePartition-APIs, 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 in der richtigen Erstellung der Partition. 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: Nicht gepufferte Schreibvorgänge, die nicht an der physischen Sektorgröße ausgerichtet sind
Das einfachste Problem ist, dass ungepufferte Schreibvorgänge nicht an der gemeldeten physischen Sektorgröße der Speichermedien ausgerichtet sind. Gepufferte Schreibvorgänge sind dagegen an der Seitengröße von 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 aus 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 werden in 512-Byte-Sektoren aufschlossen: Apps mit einem Datenspeicher verfügen in der Regel über einen 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 App die physische Sektorgröße abfragen, wie im vorherigen Abschnitt gezeigt, und sicherstellen, dass jeder Commitdatensatz auf diese Größe aufschlossen ist. Mit einem 4K-Datenträger wird dadurch sichergestellt, dass E/A-Fehler nicht fehlschlagen. Bei einem 512e-Datenträger wird dadurch nicht nur der Lese-/Änderungs-/Schreibzyklus vermieden, sondern auch sichergestellt, dass bei Verlust eines physischen Sektor nur ein Commitdatensatz verloren geht.
Protokolldateien werden in nicht ausgerichteten Blocken geschrieben: Nicht gepufferte E/A wird in der Regel beim Aktualisieren oder Anfügen an eine Protokolldatei verwendet. Apps können entweder zu gepufferten E/A-Nachrichten wechseln oder die Protokollupdates intern in Einheiten der physischen Sektorgröße puffern, um E/A-Fehler zu vermeiden, oder einen Lese-/Änderungs-/Schreibzugriff auslösen.
Um zu ermitteln, ob Ihre App ungepufferte E/A-Probleme aufgibt, stellen Sie sicher, dass Sie das Flag FILE FLAG NO BUFFERING in den _ _ _ dwFlagsAndAttributes-Parameter einordnen, wenn Sie die CreateFile-Funktion aufrufen.
Wenn Sie die Schreibvorgänge derzeit an der Sektorgröße ausrichten, ist diese Sektorgröße wahrscheinlich nur die größe des logischen Sektor, da die meisten vorhandenen APIs, die die Sektorgröße der Medien abfragen, nur die Adressierungseinheit abfragen, also die logische Sektorgröße. 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, sind:
- GetDiskFreeSpace, GetDiskFreeSpaceEx
- FileFsVolumeInformation
- IOCTL _ DISK _ GET _ DRIVE _ GEOMETRY, IOCTL _ DISK _ GET _ DRIVE _ GEOMETRY _ EX
- IVdsDisk::GetProperties, IVdsDisk3::GetProperties2
So können Sie die physische Sektorgröße abfragen:
Bevorzugte Methode für Windows 8
Mit Windows 8 hat Microsoft eine neue API eingeführt, mit der Entwickler problemlos 4K-Unterstützung in ihre Apps integrieren können. Diese neue API unterstützt eine noch größere Anzahl von Szenarien als die Legacymethode für Windows Vista und Windows 7, die weiter unten erläutert wird. Diese API ermöglicht die folgenden Aufrufszenarien:
- Aufrufen von einer nicht privilegierten App
- Aufrufen eines gültigen Dateihandpunkts
- Aufrufen eines Dateihandpunkts auf einem Remote-Volume über SMB2
- Vereinfachtes Programmiermodell
Die API hat das Format der 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 wurden APIs zum Abfragen der physischen Sektorgröße des angeschlossenen Speichergeräts für AHCI-basierte Speichercontroller eingeführt. 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 ein Codebeispiel auf MSDN bereitgestellt, in dem erläutert wird, wie eine App die physische Sektorgröße des Volumes abfragen kann.
Im obigen Codebeispiel können Sie zwar die physische Sektorgröße des Volumes erhalten. Sie sollten jedoch vor der Verwendung eine grundlegende Überprüfung der Größe des gemeldeten physischen Sektores 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 App 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 App 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 App auswerten, 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. Sie hat folgende Aufgaben:
- Erfordert erhöhte Rechte. Wenn Ihre App 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).
Problem 3: Dateiformate, die auf 512-Byte-Sektoren basieren
Einige Apps 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 Resilienzproblemen für Ihre Kunden führen würde. Es gibt jedoch Möglichkeiten für eine App, Unterstützung für die Nutzung 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 Platz interpretiert wird.
- Erwägen Sie, eine Version der App-Datenstruktur mit Unterstützung für größere Sektoren neu zu gestalten.
Problem 4: Die gemeldete Physische Sektorgröße 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 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 durch die Verwendung nativer 4K- oder 512e-Medien negativ eingeschränkt werden.
Wie ein Benutzer die logische und physische Sektorgröße für ein Volume abrufen kann
In-Box mit Windows ist ein Hilfsprogramm zum Anzeigen der Sektorgrößeninformationen für ein Volume. Versionen von Windows 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 an einer Eingabeaufforderung mit erhöhten Rechten auf, um die Informationen zur Sektorgröße zu erhalten:
fsutil fsinfo ntfsinfo <drive letter>
Für einen 4K-Sektordatenträger mit 512-Byte-Emulation ist das Feld Bytes pro Sektor auf 512 und das Feld Bytes pro physischem Sektor wie folgt auf 4096 festgelegt:

Für einen nativen 4K-Datenträger sind die Felder Bytes pro Sektor und Bytes pro physischem Sektor wie folgt auf 4096 festgelegt:

Hinweis
Wenn im Feld Byte pro physischem Sektor nicht unterstützt angezeigt wird, unterstützt der Speichertreiber IOCTL STORAGE QUERY PROPERTY nicht, oder es ist ein Fehler beim Abrufen der _ _ Informationen _ aufgetreten.
Ressourcen
- Windows allgemeinen Supportbestimmungen
- Microsoft KB-982018
- Hotfix für Windows 7 und Windows Server 2008 R2
- HyperV-Support-Anweisung
- Allgemeine Informationen zum IOCTL _ STORAGE _ QUERY _ PROPERTY-Steuerungscode
- IOCTL _ STORAGE _ QUERY _ PROPERTY Control Code
- Allgemeine Informationen zur _ _ SPEICHERZUGRIFFSAUSRICHTUNGSDESCRIPTOR-Struktur _
- Beschreibung der Standardterminologie zur Beschreibung von Microsoft-Softwareupdates
- WDK-Beispielcode mit Details zum Extrahieren der gemeldeten Informationen zur Speicherzugriffsausrichtung aus der STORAGE ACCESS ALIGNMENT DESCRIPTOR-Struktur beim Aufrufen des _ _ _ IOCTL _ STORAGE _ QUERY _ PROPERTY-Steuerungscodes
- Allgemeine Informationen zu ImageX Command-Line Optionen
- Intel-Chipsatztreiberanforderungen zur Unterstützung von 4-KB-Sektorlaufwerken