Genau das dacht ich mir nämlich, das was hier das Problem ist, ist in erster Linie das Alignment, also wo liegt ein Partitionsblock physisch auf der HDD. Da es nun anstatt üblicherweise 512Byte eben 4096Byte sind, steigt also der Teil der Daten, die gelesen werden müssen extrem, sofern die Zuordnung nicht sauber ist.
Aber (und hier kommt einer meiner Einwände) ist das gerade unter Windows nicht primär das Problem der 4kb Platten... Ein als NTFS Formatiertes Windows Laufwerk verwendet Standardmäßig eine Blockgröße von 4096Byte. Das heist, werden Dateien angefordert, so werden immer 4096Byte große Blöcke gelesen. Bei herkömmlichen HDDs mussten also bei richtig gesetztem Alignment acht Sektoren zu 512Byte hintereinander weg gelesen werden. Passte das Alignment nicht, so waren es eben neun. Was linear gesehen 12,5% mehr Aufwand bedeutet. Mit nun 4096Byte großen Sektoren muss genau einer bei richtigem Alignment angefasst werden, bei flaschen, aber gleich zwei. Ergo ein Mehraufwand von 100%...
Und genau hier liegt mein Verständnisproblem bei der 4kb Geschichte, denn diese Zuordnungsproblematik ist seit Jahren schon Thema... Gerade im Serverbereich (Datenbanken) musste man schon weit vor Windows 2000 Zeiten an den Alignments schrauben, weil der MBR seit anbegin eben nur 63 Sektoren (zu 512Byte) groß war...
Das heist also unterm Strich, man muss ein vielfaches der 4096Byte als Alignment angeben und darauf achten, das der MBR 32256Byte groß ist. Sprich als nächster Wert bietet sich hier 32768Byte an. Man reserviert also im Fall von 512Byte HDDs 64 Sektoren für den MBR und fängt die Partition ab dort an. Im Falle von 4096Byte HDDs sind es derer 8. Und schon passt das ganze.
Windows ab Version Vista/2008 Server legt standardmäßig wie ich mitbekommen habe das Alignment der ersten Partition auf 1MB fest. Sprich 1048576Byte. Das erste MB der HDD bleibt also unbenutzt. Wenn man so will, bei 512Byte HDDs eben 2048 Sektoren und bei 4096Byte HDDs eben 256 Sektoren.
Und ein Raidarray ändert an der Problematik absolut gar nichts. Denn das Raidarray erzeugt idR Stripesize Größen von 64KiloByte. Was ebenso ein vielfaches von 4096Byte ist. Sprich es gibt grundsätzlich hier keine Überlappung bei der ganzen Geschichte. Beim Raid kommt halt hinzu, das eben beim Anfordern eines 4096Byte großen Blocks (weil NTFS mit 4KB formatiert) ein ganzer 64KiloByte großer Sripe-Block gelesen werden muss. Und dieser setzt sich nun nicht mehr wie anfangs aus 128x512Byte zusammen sondern nur noch aus 16x4096Byte.
Unterm Strich heist das also, ein RaidArray ändert an der Problematik absolut gar nichts. Der Knackpunkt ist und bleibt das Alignment, und das aber nicht erst seit aufkommen der 4KB Platten, sondern schon seit Urzeiten
Es hat aber im Desktop Bereich niemanden interessiert bis dato... Einfach weil der Performanceverlust sich in Grenzen hielt, sofern man als einziger HDD Last erzeugt hat auf dem lokalen Client und wenn die Daten nicht stark fragmentiert waren.
PS:
ich beschäftige mich mit dem Thema schon seit Jahren. Wie gesagt, im Serverumfeld in Datenbank und Exchangeumgebungen ist das seit Ewigkeiten schon Thema. Seit dem 2008er Server vllt nicht mehr so stark, aber davor war auf jedenfall manuelle Anpassungsarbeit nötig um optimale Performance zu erreichen.
PS2:
das ganze hat übrigens nichts mit irgendwelchen Problematiken zwischen Controller und HDD selbst zu tun. Also das der Controller nix mit der HDD anfangen kann oder weis der Geier. Das ist ne ganz andere Geschichte und tut bei der Sache in meinen Augen nix zur Sache. Denn wenn dort keine inkompatibilitäten zu verzeichnen sind, steht und fällt alles mit dem richtigen Alignment Wert, der am besten VOR! der Installation des Betriebssystems richtig gesetzt wird. Im Nachhinein gibt das Ärger und muss nicht immer gut klappen.
.
