HD mit 4k Sektorgröße (bzw. 512e) von Win XP aus Virtual Box lesen/schreiben

[uds]

Hallo zusammen,
ich habe eine einfache Frage, für die ich leider keine Antwort fand:
Ich habe Rechner mit 2 512GB SSDs im Raid 0 Verband (tut nichts weiter zur Sache) auf Gigabyte ga-z270x-gaming 9 boards.
Auf diesen SSDs läuft Windows 10 und in einer Virtual Box Windows XP 32 bit und 64 bit (und Linux mint). Der Grund warum ich Windows XP häufig noch brauche tut zwar nichts zur Sache --> aber: es ist deshalb weil ich 5 XP-Programme noch verwende für die eine Neuanschaffung einfach zu teuer ist. (Bitte nicht auf das Thema "Windows XP ist unsicher" eingehen - die Rechner haben keine Internetverbindung)
Nun möchte ich die Daten-Platten ersetzen, diese sind noch normale Festplatten mit 512n Sektoren. Ich möchte/muss auf größere 4k-Sektor-Platten (4kn oder 512e) umsteigen.
Frage 1: Kann Windows XP 32 bit und 64 bit aus der Virtual Box problemlos auf 4k native Platten lesen/schreiben?
Frage 2: Kann Windows XP 32 bit und 64 bit aus der Virtual Box problemlos auf 4k Platten die auf 512e emuliert ist lesen/schreiben?
Beste Grüße
uds

 

[Holt]

4kn dürfte Probleme bereiten, laut Microsoft support policy for 4K sector hard drives in Windows werden 4kn Platten erst ab Win 8/Server 2012 unterstützt. Aber 4kn ist sowieso nur bei einigen, wenige Enterprise Nearline Platten vorhanden. Bei den 512e (also physikalisch 4k mit logisch 512 Byte) wird Vista mit KB 2553708 angegeben, allerdings bezieht sich dies nur auf das korrekte Alignment der Partitionen die man mit Windows anlegt.

Bei den 512e ist die Größe der physikalischen Sektoren ja im Grunde egal, man kann sie auslesen, muss sie aber nicht beachten, die verhalten sich wie die 512n Platten und laufen daher überall wo auch 512n laufen können, außer die SW sperrt sich explizit dagegen, etwas weil sie die physikalische statt der logischen Sektorgröße ausliest und auswertet. Das einzige Problem ist die Performance, denn HDDs haben pro physikalischem Sektor eine ECC die am Ende diese Sektors hinter den Daten steht. Diese wird vom Controller berechnet und zusammen mit den Daten geschrieben, nur muss dazu eben immer der Inhalt des ganzen physikalischem Sektors bekannt sein, weil die ECC je eben über die Daten des ganzen Sektor gilt.

Bei einer 512 Platte liegen nur 8 logische Sektoren auf einem physikalischem Sektor und wenn nicht alle 8 auf einmal überschrieben werden, dann muss der Controller der Platte erst den physikalischem Sektor lesen, tauscht dann in seinem RAM die Daten der überschriebenen logischen Sektoren aus, berechnet die neue ECC für den neuen Inhalte des physikalischem Sektors und kann diesen dann schreiben, aber eben erst bei der nächsten Umdrehung. Gerade bei kleinen zufälligen Schreibzugriffen kann die Schreibperformance also schon deutlich einbrechen, mehr passiert aber auch nicht!

Dies kann man zwar nicht zu 100% verhindern, aber da meist ein ganze Cluster des Filesystems geschrieben wird (keine Ahnung ob XP das auch so einhält) und die Cluster bei NTFS eben meist 4k groß sind, sie sollten eben nie kleiner als die physikalische Sektorgröße sein (dies dürfte bei XP auch nicht beachtet werden und man kann wahrscheinlich auch eine kleinere Größe der Zuordnungeinheiten auswählen), ist es kein sehr großes Problem, solange eben die Cluster des Filesystems immer die physikalischen Sektoren vollständig belegen. Dies ist der Fall wenn das Alignment stimmt, also die Anfangsadresse der Partition an einer 4k Grenze liegt. Leider ist dies bei XP normalerweise nicht der Fall, XP legt die ersten Partition normalerweise bei 31k und nicht bei 32k an.

Das war nun eine lange Rede zum Hintergrund, praktisch kannst und misst Du nur eines machen: Achte also darauf das die Startadressen der Partitionen immer ganze Vielfache von 8 sind, also an einer 4k (genauer 4ki) Grenze liegen! Dann trifft dies automatisch auch für alle Cluster zu, sofern deren Größe 4k oder ein Vielfaches davon beträgt. Dies gilt auch für SSDs, da diese auf Zugriffe optimiert sind die auf Adressen gehen die ganze Vielfache von 8 sind.

 

[uds]

Vielen Dank Holt,
das hilft mir schon mal weiter. Ja, das mit den Startadressen hatte ich bereits wo gelesen.
Ich verstehe eine Sache noch nicht:
Wenn ein Betriebssystem - mal egal welches - in der Virtual Box auf Windows 10 läuft - ist es dann nicht so, dass eigentlich Windows 10 die Festplattenoperationen übernimmt?
Sorry für diese vielleicht dumme Frage - ich bin Laie in dieser Sache.
Beste grüße
uds

 

[Holt]

Mit Virtual Box kenne ich mich nicht so aus, aber generell gibt es ja zwei Varianten wie so eine Virtuelle Maschine auf Festplatten zugreifen kann: Einmal über eine Virtuelle Festplatte, die ist dann auf dem Host nur eine Datei oder über das Durchreichen einer physikalischen Platte an die VM, womit diese dann alleine die Kontroller über diese Platte hat. In beiden Fällen sollte man darauf achten das bei den Platten das Alginment stimmt, damit die Zugriffe auf die Platte dann auch wirklich an den physikalischen 4k Grenzen erfolgen.

Windows 10 wird zwar dafür sorgen das Partition und damit die Datei die die Virtuelle Platte der VM ist, korrekt an einer 4k Grenze ausgerichtet ist, also sagen wir z.B. ab Adresse 8000ki. Num legt aber XP innerhalb dieser Datei die erste Partition ab 8031ki an, dann erfolgen alle Zugriffe von XP auf eine virtuelle Platte auf Adressen die eben keine ganzen Vielfachen von 8 sind. Wenn eine Windowsversion noch keine 512e unterstützt, so bedeutet dies einfach nur, dass es eben nicht darauf achtet das die Partitionen korrekt an den 4ki Grenzen ausgerichtet sind, die Cluster nicht kleiner als die physikalische Sektorgröße und möglichst immer ganze Cluster geschrieben werden. Außer bei der Schreibperformance hat dies aber keine weiteren Folgen und die Nachteile bei der Schreibperformance sind auch nur bei kurzen Schreibzugriffen wirklich relevant, wenn viele Daten auf einmal geschrieben werden, fällt es nicht so ins Gewicht wenn am Anfang und am Ende jeweils ein Sektor erst noch gelesen werden muss bevor er dann teilweise überschrieben werden kann.

 

[uds]

Hallo,
OK, danke Holt - nun verstehe ich nun.
Beste Grüße