4Kn: Native SATA Abenteuer (mit Windows XP x64, Truecrypt, HDTune usw.)

Ich [suchte ja schon seit einiger Zeit] eine 4Kn Festplatte an SATA oder SAS, und bin nun endlich fündig geworden, mit einer der ersten halbwegs leistbaren echten 4K Disks der Welt, einer Toshiba MG04ACA300A. Ich dachte mir ich mache dafür einen extra Thread auf, sonst geht's im anderen unter.

Sinn der Sache ist ein Kompatibilitätstest des neuen nativen Sektorformats mit alten Windows Systemen und diverser Drittanbietersoftware, die direkt auf Blockdevices zugreift.

Laut Microsoft gibt es im Toolset des Betriebssystems erst ab Windows 8.1 4Kn Unterstützung, und in keinem OS davor. Das wollen wir Mal sehen!

Hier ist die Platte also, ein 3TB SATA Modell mit schönem 4Kn Logo drauf, kein Emulationsgeschwindel mehr:


(Klicken zum Vergrößern)

Näher ran:


(Klicken zum Vergrößern)

Da ich ja plane, einen großen 12-Disk RAID-6 Array zu bauen, wollte ich zuerst die Lage ausloten, was 4Kn angeht. Das ist nun endlich möglich. Und zwar mit richtig alter Software!

Damit 4Kn tatsächlich funktioniert müssen bekanntlich die folgenden 3 Ebenen mitspielen, und die Sektorgröße auch unterstützen:

• BIOS/UEFI bei onboard Controllern bzw. Controllerfirmware im dedizierten Falle
• Controllertreiber
• Betriebssystem und Applikationen, die auf low-level Ebene mit Block Devices arbeiten

Linux und UNIX haben hier wohl weniger Probleme (obwohl das von mir ungetestet verbleiben muß dieses Mal), aber bei Windows war ich richtig neugierig!

Zuerst gehen wir Mal richtig blauäugig an die Sache ran... Daß der Intel ICH10R Treiber kein 4Kn kann - egal auf welchem MS OS, hat Intel schon öffentlich bekanntgegeben. Doch was ist wenn ich einfach einen Marvell 88SE6121 nutze, noch dazu mit dem allerletzten und seltenen Treiber 1.2.0.8400? Platte ins eSATA Dock und ab geht's (oder so).

Daß die Kacke nicht rennt - man kennt ja die hohe Windows Treiberqualität bei Marvell - war eh klar, also hier gleich die Auszüge aus dem Log, die folgenden drei Events passieren genau in dieser Abfolge hintereinander:


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)

Die Timeouts kommen dann ca. alle 30 Sekunden daher und gehen mit einem kurzen Hänger des Betriebssystems einher. Yay.

Nun besitze ich aber einen Areca ARC-1883ix-12 RAID-6 Controller der dann für'n finalen Array genutzt werden soll. Dieses Teil bringt bereits 4Kn Unterstützung mit, wie auch schon frühere Modelle von Areca, sowohl in Firmware wie auch im x64 StorPort Treiber für Windows. Also Controller testweise rein, Platte dran, und booten!

Najo, was nicht so alles geht:


(Klicken zum Vergrößern)

Nun ist es leider so, daß diverse Microsoft Tools - man erinnere sich an den ekelhaften FAT32 Formatierer von Win98 - leider oft weniger wissen und können als der Unterboden des Betriebssystems. Mit 4Kn wird der Adressraum der Platte verachtfacht, weil das kleinste adressierbare Element acht mal so groß ist - 4096 Bytes anstatt 512.

Sogar mit gutem alten MBR (Master Boot Record) sollten nun also 16TiB gehen, anstatt von 2TiB. Bei einigen 4Kn-emulierenden USB Platten soll das auch gehen, hier bei mir versagt allerdings das Microsoft Disk Management:


(Klicken zum Vergrößern)

Das sagt mir, daß die Magie unter Windows XP 32-Bit mit NT5.1 Kernel vielleicht nicht klappt. Hier habe ich aber XP x64 mit NT5.2, und damit kann ich noch auf GPT anstatt MBR ausweichen:


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)

Um Read-Modify-Write Zyklen zu meiden, wähle ich als NTFS Cluster die selbe Größe wie die Sektorgröße der HDD selbst, anstatt von 512 Byte also 4kiB. So sollte es keine Probleme geben, so denkt man.

Nun bin ich vielleicht der erste und letzte, der auf Windows XP per native SATA-over-SAS so etwas sieht:


(Klicken zum Vergrößern)

Bespielen wir das Trumm Mal, hier mit der 4K Version von "Big Buck Bunny":


(Klicken zum Vergrößern)

Einen System Volume Information Folder suche ich hier vergebens. Windows will keinen anlegen. Doch dazu sehen wir später noch ein Kuriosum. Widmen wir uns weiter Ebene 3 des "Kompatibilitätsstacks". Ich starte also HDTune, und....


(Klicken zum Vergrößern)

Ok, was ist hier passiert? Daß das gratis HDTune nicht mehr als 2TiB anspricht, weiß man, aber häh?

Doch 375GB klingen nur auf den ersten Blick nach einer schiefen Zahl. 375*8=3000! Und wir haben hier ja eine 3TB Platte!

Was hier also passiert ist, ist folgendes: HDTune hat zwar die korrekte Sektoranzahl der Platte erkannt, nicht aber die Sektorgröße. HDTune spricht die 4Kn Platte also als 512n an. Da das kleinste ansprechbare Atom also als 8 Mal so klein angenommen wird, ist auch der gesamte Adressraum plötzlich 8 Mal so klein. Ein fatales Problem, das bei echtem Zugriff auf den Datenträger Chaos auslösen muß:


(Klicken zum Vergrößern)

HDTune Pro - wie üblich seinem veralteten Gratiskollegen voraus - unterstützt die Sektorgröße aber:


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)

Trari Trara. "Betriebssystemkompatibilität" ist sichtlich ein sehr weit gefächerter Begriff, wenn es um 4Kn geht. Hier geht's nicht nur um's Betriebssystem und dessen Toolset! Jede Applikation, die eigenständig roh auf Blockdevices zugreift, muß variable Sektorgrößen (oder zum. 4Kn hardcoded) in diesem Fall verstehen können!

Spannend wird's mit anderen antiken Tools.

HDTach sollte wohl wie ich zumindest vermute nur von bereits formatierten Partitionen lesen. Da Dateisysteme das Blockdevice abstrahieren, bekommt HDTach von dem Zeug "unten rum" nichts mehr mit:


(Klicken zum Vergrößern)

Aber RICHTIG geil wird's beim uuuuralten Tool von ATTO, dem ATTO Benchmark! Da reißts einem glatt die Hosen weg, wie gut der in dieser Hinsicht scheints damals schon programmiert wurde:


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)

Das bestätigt mir, daß 4Kn, oder ggf. generell variable Sektorgrößen eigentlich kein Hexenwerk sind. Ich glaube vielmehr, daß die Entwickler allesamt zu faul waren und immer noch sind, endlich ihren 512n hardcoded Schrott ordentlich zu fixen! Der ATTO Bench ist bitte aus der Steinzeit, da gab's noch ned Mal irgendwas in der Nähe von 4Kn. Und er kann's trotzdem!!

Aber jetzt noch was spannendes, nämlich Truecrypt, einer Festplattenverschlüsselungssoftware, der ich auch nach dem Shutdown immer noch traue (hm, das is doppeldeutig). Ich habe ja Mal im Quellcode von TC rumgeschnüffelt, und folgendes in CoreUnix.cpp gefunden:

Code:

#if defined (TC_LINUX)
if (volume->GetSectorSize() != TC_SECTOR_SIZE_LEGACY)
{
  if (options.Protection == VolumeProtection::HiddenVolumeReadOnly)
    throw UnsupportedSectorSizeHiddenVolumeProtection();

  if (options.NoKernelCrypto)
    throw UnsupportedSectorSizeNoKernelCrypto();
}
#endif

Das ist natürlich nur für Linux, und hier soll's nur dann nicht gehen, wenn der Kernel ohne Cryptosupport gebaut ist. Für MacOS X gibt es [Wege]. Der Code für Windows aber sollte (mit Ausnahme bootfähiger System Volumes) immer mit 4Kn zurechtkommen, obwohl auch TC in einer Zeit geschrieben wurde, als es so etwas noch nicht gab. Im Windows Bereich findet sich für reine Datenvolumes nur Code, der jede variable Sektorgröße annehmen kann. Hier konnte ich keinen hardcoded 512n oder 4Kn Source finden!

Der Code ist möglicherweise noch niemals zuvor mit einer entsprechend nativen 4Kn SATA/SAS Disk gelaufen...

Also versuchen wir's einfach:


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)


(Klicken zum Vergrößern)

Halleluja!

Und das ganze läßt sich sauber verwenden, System Volume Information gibt's, und fsutil.exe zeigt bei Anfrage auf das Volume auch wieder eine Sektorgröße von 4096 Bytes an, was deutlich macht, daß der Truecrypt Kerneltreiber auf Windows die 4Kn korrekt versteht und "nach oben" durchreicht.

Kleiner Test mit Big Buck Bunny auf der TC verschlüsselten 4Kn Disk mit NTFS oben drauf:


(Klicken zum Vergrößern)

Ein binary diff zeigt keine Anomalien oder Inkonsistenzen, die SHA512 Prüfsummen der Datei stimmen mit der Quelle - einem reinen 512n RAID Array - überein.

Damit sind meine Tests soweit abgeschlossen, und es läßt sich ein loses Resümee ziehen.

Herzlicher Dank übrigens an Areca, die nicht nur hypermoderne PCIe 3.0 SAS/12g Controller auf XP supporten (was schon recht irre ist), sondern auch noch 4Kn möglich machen, wo es scheinbar selbst Giganten wie Intel nicht zuwege bringen, obwohl die nur mit den Fingern schnippen müßten, um einen RapidStorage Treiber zu releasen, der das kann - sofern die Motherboardhersteller mit ihrem UEFI nicht ewig schlafen.

Ein spannendes kleines Technologieabenteuer in jedem Fall...

Man verdient halt nichts dabei, wenn die Leute bestehende Hardware länger verwenden ..
Zumal die Anpassung des Treibers und die Validierung ja auch Zeit und damit Geld kostet.

Vielen Dank für den Bericht auf jeden Fall.
Interessante Sache und irgendwann werden 4Kn Platten ja dann wohl doch auch größere Verbreitung finden.

ich kanns schon verstehen wenn die industrie nicht mehr supportete legacy systeme fallen lässt. das ist halt der preis den XP nazis zahlen müssen
und in deinem fallen kanns dir ja herzlich wurscht sein. du hattest eh nie vor solche disks am onboard controller zu verwenden?

Zitat von Umlüx

ich kanns schon verstehen wenn die industrie nicht mehr supportete legacy systeme fallen lässt. das ist halt der preis den XP nazis zahlen müssen

Hat mit XP insofern nix zu tun, als dass er ja schreibt der RST Treiber für die ICH10R kann 4Kn mit keinem MS-OS.

So, ich dachte, ich serviers Mal virtualisiert an Windows 2000 und NT4, zwecks der Gaudi. Außerdem diverse BSDs, OSX usw.

Leider wird das nichts, weil sowohl VMware Player wie auch VirtualBox sowas wie "512e in Software" betreiben, wenn man 4Kn roh für Passthrough an sie verfüttert.

Die emulieren dann echt 512 Byte Sektoren für'n Gast, das zerstört irgendwie die Idee, das ganze einfach und schnell mit zig Betriebssystemen testen zu können..

Darf ich fragen, wie? Ich kann zwar Disks durchschleifen, aber komplette Controller, da seh ich keine Optionen dafür.

Muß ich das ggf. über die Configfiles erledigen?

Wie gesagt, zur Verfügung stehen VirtualBox und VMware Player. Vielleicht können die sowas gar nicht, oder mir fehlt VT-d? Ich hab nur VT-x + EPT hier.

So, Windows XP 32-Bit! Jetzt endlich dazugekommen, auch das zu testen, dank des SCSI Miniport Treibers, den Areca dankenswerterweise auch für den ARC-1883ix-12 noch anbietet. Also halt eben nativ, wenn meine VMs nicht wollen.

Platte wird sofort erkannt, und nun wundersamerweise (anders als unter XP x64) auch mit einem Master Boot Record korrekt initialisiert, hier wird wohl klar warum manche USB HDD Hersteller 4Kn für normales XP faken, weil es wohl wirklich geht:



Spannend, also wirklich ok? Beim Partitionierungsvorgang scheint es so:



Faszinierend, es geht ja doch, hier wieder mit NTFS Blockgröße 4kiB formatiert:



Tatsächlich können die XP 32-Bit Tools (anders als jene von XP x64) die Disk sauber mit MBR ansprechen und partitionieren. Einziger Nachteil gegenüber der auf XP x64 verfügbaren GPT ist natürlich die maximale Größe: Auf XP 32-Bit limitiert uns der MBR auf 16TiB. Auf XP x64 limitiert uns dank GPT nur mehr NTFS mit seinem 32-Bit Adressfeld und seinen maximal 64kiB großen Clustern; Nämlich auf knapp 256TiB.

Die Sektorgröße an sich stellt für "normale" Nutzung jedenfalls auch hier keine Schwierigkeit dar:



Somit darf für Windows XP 32-Bit gelten: 4Kn funktioniert prinzipiell, Volumes mit bis zu 16TiB sind maximal möglich. Ein Spanning/JBOD mittels Dynamischer Datenträger z.B. in Verbindung mit LUN Carving für größere Dateisysteme die mehrere Volumes umspannen jedoch funktioniert NICHT! Grund: Dynamische Datenträger auf Betriebssystemen vor Windows 8 (jedoch in jedem Fall bei XP) lassen sich nicht mit 4Kn Platten einrichten. Soll heißen: Keine Riesen-RAIDs auf XP 32-Bit mit 4Kn Volumes, bei 16TiB ist in jedem Fall Ende Gelände. Für mehr muß es dann schon XP x64 mit GPT sein!

Auch ziemlich pervers, dass die ältere XP Version 4kn besser unterstützt als die x64 Version.