4kb Datenblock HDD, Alignment doch nicht so einfach?

[ScoutX]

Vorneweg: Ich beschränke mich hier auf das Thema NTFS mit 512 kb Blöcken und Startsektor 63 (z.B. XP) und Multibootsysteme.
Da ich auch einiges unter Linux mache und auch hier bei manch einem Dateisystem in Schwierigkeiten gerate, bleibt ZFS und Konsorten außen vor.

Grundüberlegung wie in vielen Tutorials 63*4096=258048. Auf diesem Sektor würde sowohl XP als auch Vista und Co mit einem neuen Datenblock anfangen. Alle ganzzahligen Vielfachen dieser Werte sind als Anfangssektoren anzusehen.
Da ich viele Images mit Acronis und Gparted bearbeite, stoße ich trotzdem schnell an Softwaregrenzen.
Ein ums andere Mal geht die Performance z.T. in den Keller, was eigentlich nur auf ein falsches Alignment schließen lässt, obwohl ich auf jene 258048 Rücksicht nehme.
Doch finde ich die Ursache nicht immer.

Kann es sein, dass die LBA Logik uns hier irgendwie einen Strich durch die Rechnung macht.
Dass die HDD Firmware möglicherweise ähnlich wie schon bei SSDs Bugs hat?
Wie geht ihr das Problem bei Multibootsystemen und Images an?

Durch die veraltete 512kb Codierung im Bios wird uns demnächst ein Chaos entstehen. Anstatt die HDDs und Windows Systeme mit 4K als Quasistandard festzulegen (und das Bios immer noch nicht zu berücksichtigen) sollte man endlich von den Zylindern und Sektoren völlig abrücken. Der Festplatte sollte es doch genügen, ob man 512 oder 4096 kb große Sektoren haben will und dann eigenständig ihre Partitionstabellen optimal anpassen. Das Hickhack zwischen LBA und CHS, was eigentlich nicht mehr existiert, ist doch völliger Mumpitz.

 

[Ernst@at]

Bei einer bereits erfolgten Partitionierung interessiert es weder das System, das Filesystem, oder ein Backup/Restore Tool, wo die Partition liegt. Legt man diese auf einer neuen derartigen Platte zuerst an, bevor man die formatiert oder ein System draufinstalliert, kann nichts mehr schiefgehen. Anlegen von Partitions per Datenträgerverwaltung XP oder sonstigen nach DOS-Konventionen ausgerichteten Methoden sollte man dann aber immer unterlassen.
Ist der Sektor des Partitionbeginns ein Vielfaches von 8, dann kann dies keinesfalls der Grund für Performanceprobleme sein (außer, der Jumper ist reingesteckt )

 

[ScoutX]

Das sagst Du. Aber genau das Beispiel des Jumpers ist interessant. Es erhöht durch einen Firmwarehack den 63. Sektor auf den 64. bzw. +1 in der LBA Logik. Angeblich soll der Jumper aber nicht Vista/7 beeinflussen. Wie das?. Wenn doch alle Sektoren +1 verschoben sind, so auch der normale Startsektor der neueren Windowssystem. Die HDD weiß nicht vorher, was auf sie draufkommt und um hier zu selektionieren.
Davon mal abgesehen ist der Jumper draussen. IDE Zeiten habe ich hinter mir gelassen.

 

[Ernst@at]

Ich lese nur die englische Beschreibung - vielleicht steht in einer deutschen was anderes, aber in meiner dezidiert, dass der Jumper nur bei XP und einer einzigen Partition anzuwenden ist, in allen anderen Fällen wo nötig, mit dem blöden align-Tool gearbeitet werden muss.
Auf die Idee, gleich eine sinnvoll alignte Partitionierung draufzumachen, kommt natürlich keiner.

 

[ScoutX]

Lerne ich doch noch etwas dazu. Ich habe es auch im Eingangspost geahnt und Ernst@at
lag falsch.
http://www.au-ja.de/review-western-digital-caviar-green-wd15ears-vs-wd15eads-2.phtml

Also doch Sch. für Multiboot. Zum Glück lag dass Problem nicht vor dem Bildschirm.

 

[Ernst@at]

Ich habe es auch im Eingangspost geahnt und Ernst@at
lag falsch.

Scheint doch eher ein Problem vor dem Bildschirm zu sein - ich hab genau das geschrieben, was auch am Aufkleber und dem verlinkten Artikel steht.
Das ist bei Multiboot verschiedener Systeme nicht anders - das Align Tool verwenden! Oder wo siehst Du hier eine Diskrepanz?

 

[ScoutX]

Bist Du meinem Link gefolgt und siehst Du die Performanceeinbussen der 4k Platten?
Genau dieses habe ich beobachtet. Für dich nochmal Konkret Seite 6 bis 9 des Tests.
Hast Du auch gelesen, dass alle Tests mit alligntem Versionen durchgeführt wurden und direkt auf die LBA Logik (Emulation) eingegangen wird.

Das hat nichts mit Tools und Jumper zu tun.
Diese HDDs kann man weder für Multiboot noch große VMWare Images gebrauchen.
Die EADS funktionierte Recht moderat (siehe hier auch IOmeter), die EARS ist ein 4 kb Sektoren Datengrab.

 

[Ernst@at]

Und? Hat sich doch bei denen keiner Gedanken gemacht, ob die entsprechenden Tests auf die Clusterzuordnung Rücksicht nehmen - Da wird lustig eine Riesen-Testdatei angelegt und dann wild durch die Gegend geackert, oder überhaupt auf der physischen Platte gearbeitet, ohne dass sich eines der Testtools um ein 4K Alignment scheren würde.
Tests von anderen Komikern beinhalten dies wenigstens als Hinweis zu den Benchmarkergebnissen, welche der Tools da nicht aligned arbeiten.
Einzig bei WinRAR-Operationen (unrar von vielen kleinen Dateien) tritt der Effekt in gleicher Weise bei Filesystem-Operationen auf, ohne dass man eine Erklärung dafür gehabt hätte; aber auch da hat sich keiner die Mühe gemacht, mit einem I/O Trace nachzusehen, was da wirklich passiert...

Das einzige was die Brüder aligned haben, waren die Partitions - bei den Tools konnten sie leider von den Entwicklern keine kriegen, welche ihre Operationen auf 4K alignment abstimmen.

Diese HDDs kann man weder für Multiboot noch große VMWare Images gebrauchen.

Hast Du eine Ahnung, wie VMware arbeitet? Schon mal was von Sparse gehört?
Und was ändert "Multiboot" an der Sache? - ist doch das gleiche wie mehrere Partitions auf einer HDD

 

[ScoutX]

Jetzt mal ehrlich: Warum sollte überhaupt eines dieser Tools aligned arbeiten?
Es ist einfach ein Stück Software, das Daten zum Bus schickt. Was daraus wird, übernimmt der Controller von Mainboard und Festplatte. Da das Bios nur 512kb Pakete versteht, nimmt jede HDD, ob Windows 7 installiert oder was auch immer nur 512kb Pakete am Controller an.
Das ist eben so. Fakt. Ich weiß einige Tools mögen HALs umgehen und das Betriebssystem (in diesem Fall Vista Sp2) ebenso.
Aber genau wenn sie dies tun, sieht man schon die Problematik. Der HDD- Controller packt dies nicht. Jetzt komm mir nicht damit, dass man als Softwareentwickler auch noch den Festplattenherstellern mit irgendwelchem Bogus und Hackmethoden unter die Arme greift.
Wenn Iometer unter Vista schlechte Ergebnisse erzielt und solche einfach gehaltenen Tools ala Sandra, die nichts umgehen, auch schlechte Ergebnisse liefern, was denkst Du, was normale Anwendungen anders machen. Wofür ist den NCQ und Co. zuständig? Die Daten kommen eh nie so an, wie man sie erzeugt, was auch gut so ist.
Die ersten SSDs sind durch die Emulation in die Knie gegangen und konnten dies nur durch leistungsfähigere Controller kompensieren. Die HDDs haben diesen offenbar nicht.
Dazu kann man bei HDDs auch nicht auf mehr Lanes bzw. Speicherchips zur gleichzeitigen Datenbearbeitung zurückgreifen.

Fakt ist Zitat Auja:

Hierbei entsteht allerdings ein Performance-Problem, welches an MLC-basierende Solid-State-Drives erinnert: Wird ein Datenblock über einen 4 KByte großen Sektor hinaus geschrieben, muss die Festplatte den benachbarten physikalischen Sektor zunächst lesen, dessen acht logische 512 Byte Sektoren bearbeiten und kann den veränderten 4 KByte Sektor erst nach einer weiteren Umdrehung schreiben.

Da kann man nichts beschönigen. Wenn eine Emulationsschicht vorhanden ist, ist sie eben da. Es interessiert weder das Betriebssystem oder eine irgendwie anders geartete Software.
Was dabei rauskommt sieht man.

Warum stellst Du eigentlich immer Dinge im Raum, wie z.B. Sparse?
A) Sollte man eh keine Sparse Geschichten fahren, wenn man Performance will und Fragmentierung verhindern, sondern gleich eine Partiton komplett erstellen.
VMware arbeitet nicht grundsatzlich damit sondern kann es.
Davon abgesehen hat dies keine Auswirkungen auf die Problematik, dass die eine Festplatte langsam ist, die andere nicht. Denn VMware muss schließlich mit dem Hostsystem und dessen Dateisystem arbeiten. b) ist die virtuelle Maschine eh ein Krüppel, da dessen Bios weitestgehend auf dem alten BX Chipsatz beruht. Hier haben wir nur eine weitere nicht unproblematische Emulationsschicht mehr.
Multiboot: Weil Betriebssysteme ala XP und vielen, vielen Linuxvarianten die Daten im 512 Format senden und daher statistisch mehr Overhead produzieren und wie eingangs erwähnt sich andere Linuxdateisysteme mehr als schwer tun. Einige kann man auch schlechterdings nicht alignen.
Zum Schluss. Die Bootloader sind auf den 4KB Quatsch nicht ausgerichtet. Was denkst Du was passiert, wenn sich diverse Bootloader automatisch konfigurieren. MBR hier weg, da Grub hin. Das Alignement geht größtenteils verloren oder es ist kaum noch steuerbar. Sollte man per Hand an den Images/Partitionen unbedingt basteln/alignen wollen, wird der Loader schlimmstenfalls das Betriebssystem erst gar nicht mehr finden. Selbst schon bei gleichzeitigem XP und Windows 7 gibt es Probleme.
Kann man argumentieren, dass sich die Softwareindustrie etwas einfallen lassen muss.
Wird sie aber absehbar nicht. Wenn man bedenkt, dass sich das sehr beliebte und mit mehreren Entwicklern besetzte Gparted bisher keine Lösung für den 4k support hat einfallen lassen und sich die gesamte Linux Community sich sehr schwer mit dem Thema tut, sehe ich auch kaum Entwicklungsfortschritte.

Was mich wieder zu dem Fazit führt. Irgendwelche Emulationsschichten sind für den Allerwertesten. Sollte das Bios keine 4k können, sollte man auch keine HDDs dafür entwickeln.
Oder man greift zumindest auf bessere Journaling Dateisysteme zurück, die auch den SSDs gut getan haben, sofern sie zum Einsatz kommen.

 

[Ernst@at]

Ich hab das leichte Gefühl, du bringst da irgendwas durcheinander oder gehst von völlig falschen Voraussetzungen aus.
Das BIOS hat mit deinen vermeintlichen "512B Paketen" sowas von überhaupt nichts zu tun. Das schaufelt den I/O Request Block bloß zum Controller.

Der macht dann, unabhängig vom Command Code (single/multiple Block) dann von sich aus weiter, kommuniziert mit der Device - und die macht dann nach eigenem Gutdünken DMA's in Längen, wie es ihr beliebt. Das auch via NCQ, was mit dem 4k Problem noch weniger zu tun hat, als Du da annimmst. Das einzige, worauf es bei der Kommunikation mit derartigen 4k-Devices ankommt, ist die durch 8 teilbare Beginn-LBA und die durch 8 teilbare Anzahl von Blöcken in einem Write-Request.

Es liegt ganz einfach in der Natur der Sache, dass die bisher eifrigst von Benchmark-Fanatikern verwendeten Tools schon einige Jahr(zehnt)e am Buckel haben, als noch keiner von was anderem als 512B geträumt hat, und dementsprechend auch keine Veranlassung, ihre I/Os an 4K Boundaries auszurichten. Die FBA512-Technik ist inzwischen schon locker 35 Jahre alt. Eigentlich scheint keiner damit gerechnet zu haben, dass WD hier mit der Schnapsidee der Emulation hausieren gehen würde. Die nächste Generation hat einfach 4K Sektoren und das wars dann - Jeder, der derzeit ein RAID mit mehr als 2TB auf einer AMD SB ab 750 betreibt, hat dort keine 512B Sektoren mehr - sondern 1K, 2K oder 4K, je nach Arraygröße.

Einfach deshalb, weil die Device nach uraltem ATA-Brauch selbt kundtut, in welcher Blockgröße sie als Unit of Work zur Zusammenarbeit bereit ist. Alle, die sich nicht darum gepfiffen haben, was die Device da per Konvention diktiert, haben jetzt ein Problem - wie die stand-alone Programme a'la Bootloader - die lesen einen Block in die vorgesehene I/O Area ein und bekommen gratis die dahinterliegenden 3,5K zerstört. Im obigen RAID-Beispiel wird die etwas andere Blockgröße vom BootROM für den Array so kundgetan, und es funktioniert bei den neueren Systemen klaglos, das NTFS selbst bei XP hat selbst auch nie ein Problem damit - als Datenplatte.

Geht man jetzt bei NTFS davon aus, bei diesen Platten mindestens eine Clustersize von 4K definieren zu müssen, so wissen wir hoffentlich auch, dass sich gewisse systemnahe Dinge um diese Ordnung auch nicht scheren - Paging findet immer in 4K Blöcken statt. Änderungen in der $MFT oder $Bitmap könnten davon genausgut ausgenommen sein (ich hab zwar schon hunderte I/O Traces PHY gemacht, aber nie darauf geachtet) und wären eine Erklärung für das Benchmark-Disaster. Dateizugriffe selbst funktionieren aber immer brav clusterweise (was in Deinen Vorstellungen auch anders aussieht als die Realität)

Mit virtuellen Maschinen arbeite ich schon seit 35 Jahren und glaube daher sagen zu können: auch da liegst Du meist abseits...

Benchmarken kann heute jeder Depp, es fehlt aber an der Quali der Leute, die das publizieren, es dann auch richtig zu interpretieren und nicht einfach einen Haufen bunter Balken- oder sonstiger Diagramme unter die DAUs, Noobs und PseudoExperts zu werfen, die dann die abenteurlichsten Märchen daraus spinnen. Deines hat mir diesen Morgen versüßt