[Sammelthread] Advanced Format - 4kB Sektoren bei HDDs

Meinst du jetzt mit Software-RAID wirklich "dynamische Disks"? Also nutzt du Windows dafür... oder SoHo-RAID über Intel RST ect.?

Und welche Performance erzielst du aktuell und welche erwartest du?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Genau.. ich meine ein Software-RAID mit dynamischen Disks.

Mit den Leseraten bin ich eigentlich ganz zufrieden. Das sie nicht so hoch sein können wie bei einem teueren Controller, ist mir klar.
Aber von der Schreibrate hab ich schon ein bisschen mehr erwertet.



Uploaded with ImageShack.us
 
OK, 36MB/s ist in der Tat zu wenig... ist ja weniger als eine Platte alleine liefern kann.

Wie kommst du darauf, dass das ein 4k-Problem sein soll? Ab Windows Vista aufwärts, das schließt eben Server 2008 und R2 ein, sollte Windows sich um die richtige Anordnung kümmern.
Auch gibt es ja menes Wissens noch keine echten 4k-Platten, d.h. alle geben sich nach außen immer noch als 512-Sektoren Platte erkennbar und die Firmware übernimmt den Rest.

Egal, betrachte mit DiskPart das Volumen/die Partition. Das wird dir sagen, wie es ausgerichtet ist:

diskpart
list disk ($array_nr auslesen)
select disk $array_nr
list partition ($partition_nr auslesen)
select partition $partition_nr
detail

Du bekommst jetzt u.a. "Offset in Bytes" als Ausgabe. Wenn die Zahl durch 4096 glatt teilbar ist, d.h. du als Ergebnis eine Ganzzahl erhältst, wurde das 4k-Alignment beachtet.

Was ich in den Sternen steht: Das Array verteilt sich ja über mehrere Festplatten. Wenn man selbst nun auf eine entsprechende Anordnung geachtet hat muss das noch lange nicht bedeuten, dass das RAID das physikalisch auch so umsetzt... du kannst nur prüfen, wie das dir angezeigte künstliche Volumen aussieht.

Aber wie gesagt... die 4k-Problematik existiert eigentlich nur in der Theorie, da es noch keine reinen 4k-Platten gibt und jeder Hersteller per Firmware gegensteuert. Daher die Frage: Wie kommst du darauf, dass das ein 4k-Problem ist?
 
Aber wie gesagt... die 4k-Problematik existiert eigentlich nur in der Theorie, da es noch keine reinen 4k-Platten gibt

Eben darum gibt es die Problematik. Wenns die blöde Emulation nicht geben würde gäbs auch kein Alignment auf das man achten muss.

und jeder Hersteller per Firmware gegensteuert.

Ich kenns bisher nur von WD, und dazu muss explizit n Jumper gesetzt werden.
 
@ magicalMistoffelees:

OK: 32256 / 4096 = 7,875 - also nicht optimal ausgerichtet. Dann lösche mal die Partition in diskpart und erzeuge eine neue. Bspw. über "create partition primary align=64" (dann empfiehlt es sich wohl auch, 64k als Blocksize für das NTFS-Format zu wählen).


@ mueder joe:
Moment. Das eigentliche Problem ist doch, dass wenn bei einer nativen 4k-Platte eine Ausrichtung gewählt werden würde, die kein Vielfaches von 4kb ist, es zu Performance-Problemen kommen würde.
Jetzt habe ich einfach einmal die These aufgestellt, dass es keine Laufwerke gibt, die sich als 4kb-Laufwerk identifizieren. Alle diese Laufwerke haben im Endeffekt also eine angepasste Firmware, die wie auch immer sicherstellt, dass die Festplatte es schon selber "richtig" macht, auch wenn nach außen suboptimal ausgerichtet wurde. Nennen wir diese Funktionalität "Emulation".

Die von dir angesprochenen Jumper gab es bei der ersten 4k-Generation bei WD und auch anderen Herstellern. Siehe dazu WD Caviar Green Absatz "Kann ich eine Advanced Format-Festplatte in meinem System einbauen?".

Diese Emulation schien also optional zu sein. Wenn das stimmt, gibt es doch native 4k-Laufwerke...

Aber von dem Weg ist man weg. Aktuelle Laufwerke lösen das transparent in der Firmware. Hitachi dazu: http://www.hitachigst.com/tech/tech...ACEA749882577AE006F3F05/$file/AFtechbrief.pdf

Insofern sollte es eigentlich wenn überhaupt nur bei Platten der 1st Gen 4k-Platten geben... und auch nur dann wenn suboptimal ausgerichtet worden ist und sich keine Firmware um die Korrektur kümmerte bzw. diese Funktionalität nicht aktiviert war. Ob die angesprochene WD-Platte jetzt so eine ist, konnte ich gerade nicht in Erfahrung bringen...

Widerspruch?
 
Wenn die Platte nach außen hin mit 4K arbeiten würde wärs nach meiner Auffassung garnicht möglich oder zumindest nötig was kleineres als 4K zu adressieren, da 1 Sektor imho die kleinste Einheit darstellt. Damit wäre das alles garnicht mehr nötig, alles wäre wie früher, nur dass eben in 1 Sektor mehr Daten passen. Was willst dann noch ausrichten?

Und nein, es gibt keine "native" 4K Platte, die auch nach außen hin mit 4K arbeitet. Zumindest ist mir noch keine untergekommen. Und ich hab die XP Spezies auch noch nicht schreien hören, denn diese HDDs würden da nicht mehr laufen. Genau deshalb gibts ja die Krücke am Bein

Widerspruch? Ich hab den Hitachi Text nicht komplett gelesen, aber wenns so super transparent in der Firmware laufen sollte (ob die Firmware überhaupt was mit der logischen Schicht anfangen kann?), warum haben die Hersteller dann immernoch alignment Tools am start und warum gibts dann Leute die bei falschem Alignment grottige Schreibraten haben? Btw, die neuen Hitachi's sollen doch auch physisch wieder 512 Byte Sektoren haben.

Ich behaupte jetzt mal dass das Thema erst vom Tisch ist wenn wir 4K Platten ohne Emulation bekommen oder die 4K Sektoren wieder abgeschafft werden. Das wird allerdings noch dauern, da es weder Enterprise-Platten noch Controller gibt die das können.
 
Zuletzt bearbeitet:
@Whistl0r

Wenn ich eine primäre Partition erzeuge, stimmt das alignment.
Allerdings kann ich damit dann kein RAID-5 erstellen.

Sobald ich die Festplatte in einen dynamische Datenträger umwandle, wird eine Partition auf dem Datenträger erstellt und das mit einem Offset von 31KB.

Ich habe auch mal ein bisschen gegoogelt. Der Offset bei dynamischen Datenträgern ist wohl fix und kann nicht geändert werden.
 
Wenn die Platte nach außen hin mit 4K arbeiten würde wärs nach meiner Auffassung garnicht möglich oder zumindest nötig was kleineres als 4K zu adressieren, da 1 Sektor imho die kleinste Einheit darstellt. Damit wäre das alles garnicht mehr nötig, alles wäre wie früher, nur dass eben in 1 Sektor mehr Daten passen. Was willst dann noch ausrichten?

[...]

warum haben die Hersteller dann immernoch alignment Tools am start und warum gibts dann Leute die bei falschem Alignment grottige Schreibraten haben? Btw, die neuen Hitachi's sollen doch auch physisch wieder 512 Byte Sektoren haben.
Wenn du eine native 4K-Platte und ein aktuelles Betriebssystem das mit 4K-Sektoren arbeiten kann hast, solltest du keinerlei Probleme haben, völlig richtig.

Jetzt verwendet aber nicht jeder ein aktuelles Betriebssystem. Auch gibt es Anwendungen, die nicht die API des Betriebsystems verwenden und nur 512-Byte-Sektoren unterstützen. Was tun? Weiterhin 512-Byte-Sektoren Platten neben den neuen 4K-Platten anbieten? Könnte man - nur würde das nicht eher eine Umstellung verlangsamen? Das AF bringt schließlich wertvolle Vorteile für den Anwender:

  • Identisch mit Paging-Size des Prozessors
  • Zuverlässiger, da mehr ECC-Informationen gespeichert werden
  • Bessere Fehlerkorrektur

Die Hersteller haben sich gemeinsam dafür entschieden, die Vorteile nicht zurück zuhalten und AF einzuführen. Für den Übergang hat man sich die Emulation einfallen lassen.

Zur Emulation:
Früher passierte beim Lesen eines logischen Sektors folgendes: Das Betriebssystem setzte den Befehl "Gib mir Sektor 123" an den Platte ab. Der Controller konnte nun den physikalischen Sektor 123 (LBA) auslesen. Kein Problem - alles war Deckungsgleich. Das OS erhielt nun also die 512 Bytes ab Adresse 123 zurück.
Bei 4K-Platten mit Emulation sieht es anders aus: Der Befehl vom OS lautet gleich, da das OS nichts von der 4K-Fähigkeit weiß. Der Controller muss jetzt erst einmal hingehen und schauen, in welchem physikalischen Sektor der logische Sektor 123 enthalten ist - dafür gibt es intern ein Mapping. Nachwievor liest die Platte physikalische Sektoren - sprich es landen gleich 8 logische Sektoren im Cache. Der Controller liefert jetzt halt nur die 512 Bytes zurück, die dem Mapping entsprechen.

Wenn jetzt mehrere Sektoren am Stück gelesen werden, geht es richtig ab: Denn diese liegen ja bereits im Cache ;-) Folglich beeinflusst die Emulation die Lesegeschwindigkeit eher positiv als negativ.

Anders sieht es leider bei einem Schreibvorgang aus: Die Festplatte selber arbeitet bekanntlich mit physikalischen Sektoren. Wenn jetzt ein veränderter 512-Byte-Sektor kommt, dann liest der Controller der 4K-Platte also den physikalischen Sektor (4096 Bytes) aus, in welchem sich dieser Bereich laut Mapping befindet (siehe oben). Verändert die 512 Bytes und schreibt den physikalischen Sektor, also die gesamten 4096 Bytes wieder auf die Platte. Das nennt sich "Read-Modify-Write-Zyklus". Ganz schön ineffektiv... man stelle sich vor 8 zusammenhängende 512-Byte-Sektoren kommen: Das ist genau ein physikalischer Sektor. Aber nach meiner Erklärung würden hierfür 8 Lese- und 8 Schreibvorgänge nötig. Glücklicherweise ist die Festplatte klug: Da sie weiß, dass 8 logische Sektoren in einen physikalischen Sektor passen, wartet der Controller, bis 8 Sektoren eingetroffen sind, um die Änderung an den logischen Sektoren dann in einem Stück schreiben zu können.

Hier kommt nun eben die Ausrichtung ins Spiel: Wenn die Partition bei dem logischen Sektor 63 beginnen würde, könnten keine 8 logische Sektoren am Stück geschrieben werden, da diese zwei physikalische Sektoren benutzen würden. Die Optimierung funktioniert also nicht mehr so gut. In dem Falle würde die Platte also bis zu einer Art Timeout (alle x Zeiteinheiten schreibt der Controller seinen Cache auf die Platte, "Flush" genannt) warten, da sie die 8 Sektoren nicht vollbekommt. Das summiert sich :/

Der aufmerksame Leser wird sich jetzt womöglich fragen: Auch bei ausgerichteten Platten kann es vorkommen, dass sich eine Datei über mehrere Sektoren erstreckt. Somit müssten diese teuren "Read-Modify-Write-Zyklen" auch so vorkommen!
Richtig, tun sie! Bei Daten die nicht genau in 8 512-Byte-Sektoren passen ist es unvermeidbar. Aber das ist verschmerzbar... bedenken wir, dass es solche teuren Zyklen auch schon zu 512-Sektor-Zeiten gab. Wenn hier weniger als 512 Bytes geschrieben werden mussten, hatten wir auch einen ineffektiven Schreibvorgang. Schreibvorgäng von physikalischen Sektoren dauern bei 4K ja nicht länger.
Aber mit der passende "Allocation unit size" (=Cluster Größe) beim Dateisystem (4096 bei NTFS) kann man dafür sorgen, dass man die eventuelle Auswirkungen der Emulation auf ein Minimum reduziert.

Wir wussten:
Emulation ist prinzipiell schlecht. Sie verhindert, dass etwas nativ verwendet wird.

Wir wissen nun:
1) Beim Lesen stört uns die Emulation überhaupt nicht. Im Gegenteil: Bei nicht 4K-fähigen Betriebssystemen ist der Lesevorgang sogar schneller, weil weitere logische Sektoren bereits im Cache sind (es passen 8 512-Byte Sektoren in einen physikalischen AF-Sektor).

2) Emulation ist gut, weil wir die Platten so schon heute nutzen können (zuverlässiger, bessere Fehlerkorrektur).


Btw, die neuen Hitachi's sollen doch auch physisch wieder 512 Byte Sektoren haben.
Tja... es gibt leider keine Möglichkeit zu erkennen, ob oder ob nicht - Dank der Emulation. In den Spezifikationen steht 512 bei Sektorengröße, was viele als Beweis werten. Ich selber bin da skeptisch, weil alle Hersteller untereinander ein Abkommen geschlossen haben, welches sie schlichtweg verpflichtet, dass nur noch Modelle mit AF gerfertigt werden dürfen.

Ich habe hier aber eine Anfrage bei Hitachi offen. Sobald ich eine Antwort habe, kann ich sie hier mitteilen.


Ich behaupte jetzt mal dass das Thema erst vom Tisch ist wenn wir 4K Platten ohne Emulation bekommen oder die 4K Sektoren wieder abgeschafft werden. Das wird allerdings noch dauern, da es weder Enterprise-Platten noch Controller gibt die das können.
Ähnlich wie IPv6 arbeitet man schon seit 10 Jahren am AF. Das Format hat einfach nur Vorteile... der einzige Nachteil ist eben der Wunsch, abwärtskompatibel zu sein, wofür man die Emulation entwickelt hat.

Wie gesagt, die Hersteller behaupten, dass sich diese in den Fake-4K-Platten nicht spürbar auswirkt. In der Theorie ist es gut begründet, hoffe das geht aus dem Text hervor. In der Praxis ist das Gegenteil auch schwer nachweisbar, da die neuen Platten allgemein ja schneller sind. Der Skeptiker würde jetzt sagen: Wie schnell die Platten wohl ohne Emulation wären... ;-)


@Whistl0r

Wenn ich eine primäre Partition erzeuge, stimmt das alignment.
Allerdings kann ich damit dann kein RAID-5 erstellen.

Sobald ich die Festplatte in einen dynamische Datenträger umwandle, wird eine Partition auf dem Datenträger erstellt und das mit einem Offset von 31KB.

Ich habe auch mal ein bisschen gegoogelt. Der Offset bei dynamischen Datenträgern ist wohl fix und kann nicht geändert werden.
Nein, das ist definitiv möglich. Das habe ich schon selber gemacht. Schon zu Windows Server 2003 Zeiten. Damals mit diskpar aus dem ResKit, aber mit diskpart müsste es auch gehen - den Align-Befehl gibt es dort auch. Was wirft dir "fsutil fsinfo ntfsinfo LW-Buchstabe:" (wobei LW-Buchstabe eine Partition auf dem Array ist) aus?
 
Zuletzt bearbeitet:
Ich weiß es ist spät, aber ich seh in dem langen Text jetzt eigentlich nix was meiner ausführung zum 4K-Thema widerspricht.

Beim Hitachi-Thema hast auch Recht, natürlich ist die Info aus der Spezifikation. Woher sonst.
 
Zuletzt bearbeitet:
Ich widerspreche dir auch nicht. Ich habe dir eigentlich nur eine Antwort auf die im Absatz
Widerspruch? Ich hab den Hitachi Text nicht komplett gelesen, aber wenns so super transparent in der Firmware laufen sollte (ob die Firmware überhaupt was mit der logischen Schicht anfangen kann?), warum haben die Hersteller dann immernoch alignment Tools am start und warum gibts dann Leute die bei falschem Alignment grottige Schreibraten haben?
aufgeworfenen Fragen geben wollen ;)

Ich hatte das Gefühl mein vorheriger Beitrag hätte angedeutet, dass die Firmware (damit meine ich die Emulation) sich um falsche Partitionierung und deren Auswirkungen kümmern würde. Das wäre falsch. Das macht die Emulation nicht. Daher der etwas ausführliche Beitrag...
 
OK alles klar ;)

Falls die WD20EARS den Alignment-Jumper haben sollte könnte der in dem Fall mit den dynamischen Datenträgern helfen. Die Daten sind danach aber imho weg, man darf alles neu erstellen. Ich weiß aber grad nicht ob die EARS die Möglichkeit noch haben oder nicht.
 
Tja... es gibt leider keine Möglichkeit zu erkennen, ob oder ob nicht - Dank der Emulation. In den Spezifikationen steht 512 bei Sektorengröße, was viele als Beweis werten. Ich selber bin da skeptisch, weil alle Hersteller untereinander ein Abkommen geschlossen haben, welches sie schlichtweg verpflichtet, dass nur noch Modelle mit AF gerfertigt werden dürfen.

Ich habe hier aber eine Anfrage bei Hitachi offen. Sobald ich eine Antwort habe, kann ich sie hier mitteilen.

Ich habe bereits direkt vom Hitachi Support die Aussage, daß es sich bei den 7K3000er Platten tatsächlich um echte 512Byte Sektoren handelt - also keine AF Platten. - wie es mit den 5K3000ern aussicht kann ich nicht sagen, da hatte ich nicht nachgefragt.

AF Platten haben mit 2 Problemen zu kämpfen.
1. die heilige Kuh "Abwärtskompatibilität" - daher auch diese eigentlich sinnfreie, weil performancekostende, zwischengeschaltete 512Byte Sektor-Emulation - sinnvoll wäre es hier, wenn man diese wenigstens für aktuelle Betriebssysteme abschalten könnte, dies scheitert aber wiederum an an Punkt 2.
2. Bislang unterstützt keine Hardware diese Platten nativ! Bei 10 Jahren Entwicklungszeit eigentlich ziemlich traurig!

Fakt ist hier wird mal wieder eine völlig unausgereifte Technik in den Markt gedrückt - ich hoffe wirklich, daß man sich hier auf die Aussage von Hitachi bezüglich "NO AF" verlassen kann. Die Vorteile von AF, wie z.B. effektivere Fehlerkorrektur, will ich hier gar nicht in Abrede stellen - nur warte ich bis das ganze auch wirklich ausgereift ist und die Hardware verfügbar ist, bis dahin kaufe ich nur Platten ohne AF, z.B. Hitachi 7K2000 HDS722020ALA330 2 TB Intern.

ciao
Lothar
 
Zuletzt bearbeitet:
Ich habe bereits direkt vom Hitachi Support die Aussage, daß es sich bei den 7K3000er Platten tatsächlich um echte 512Byte Sektoren handelt - also keine AF Platten. - wie es mit den 5K3000ern aussicht kann ich nicht sagen, da hatte ich nicht nachgefragt.
Kann ich jetzt bestätigen:

Ich habe sowohl vom DE- als auch US-Support die übereinstimmende Auskunft erhalten, dass die 7K3000-Serie noch native 512-Byte-Sektoren Platten sind.

Keine Spur von AF.


AF Platten haben mit 2 Problemen zu kämpfen.
1. die heilige Kuh "Abwärtskompatibilität" - daher auch diese eigentlich sinnfreie, weil performancekostende, zwischengeschaltete 512Byte Sektor-Emulation - sinnvoll wäre es hier, wenn man diese wenigstens für aktuelle Betriebssysteme abschalten könnte, dies scheitert aber wiederum an an Punkt 2.
Naja, wir wissen nicht, ob 512e-Platten Performance kosten. Wir gehen höchstens davon aus, weil wir denken, dass allgemein Emulation vs. Nativ immer kosten muss.

Aber ob es real kostet, wissen wir nicht und werden wir wohl nie erfahren: Die neuen Festplatten-Serien sind alle mindestens so schnell wie die Vorgängerserie. Meistens sind sie schneller. Fertig. :)

Das wird auch zukünftig so sein... irgendwann zu kommen und zu sagen, "Hey - die Festplatten sind gar nicht schneller geworden, der Zuwachs liegt jetzt nur an der nativen Unterstützung...." wird wohl nie passieren.

Also bringt es nichts sich daran aufzuhängen, solange nicht wirklich der Nachweis erbracht wurde, dass 512e reale Nachteile hat.

2. Bislang unterstützt keine Hardware diese Platten nativ! Bei 10 Jahren Entwicklungszeit eigentlich ziemlich traurig!
Also das ist kein Hardware-Problem... wenn überhaupt ein Software-Problem. Ich denke du spielst auf das Schweigen der RAID-Hersteller an... das einzig mir vorstellbare Problem: Die Software - also die Logik des RAIDs - muss evtl. angepasst werden, so dass nicht alle 512 Bytes auf einer anderen Platte landen, sondern eben erst alle 4096 Byte zur nächsten Platte gesprungen wird. In diesem Zusammenhang wäre dann sicherlich auch interessant, welche Auswirkung ein Mischbetrieb auf die Paritätsdaten hat.

Fakt ist hier wird mal wieder eine völlig unausgereifte Technik in den Markt gedrückt - ich hoffe wirklich, daß man sich hier auf die Aussage von Hitachi bezüglich "NO AF" verlassen kann. Die Vorteile von AF, wie z.B. effektivere Fehlerkorrektur, will ich hier gar nicht in Abrede stellen - nur warte ich bis das ganze auch wirklich ausgereift ist und die Hardware verfügbar ist, bis dahin kaufe ich nur Platten ohne AF, z.B. Hitachi 7K2000 HDS722020ALA330 2 TB Intern.
Das mit dem Fakt finde ich, kann man als Außenstehender nicht abschließend beurteilen. An AF wird schließlich schon 10j gearbeitet. Es sind halt nicht nur die Plattenhersteller betroffen, sondern eben auch die Software-Leute... und das macht die Sache so kompliziert.

Wie willst du ein glaubhaftes "Läuft!" von jemanden erwarten, wenn dieser gar nicht die Zeit hatte, Langzeittests zu machen? Entweder prescht ein Hersteller nach vorne mit dem Risiko irgendwann Fehler auf Grund neuer Erkenntnisse einräumen zu müssen, oder man schweigt eben bis abschließende Ergebnisse vorliegen.
 
Also das ist kein Hardware-Problem... wenn überhaupt ein Software-Problem.
Im weitesten Sinne Ja!
Die Firmware von Controllern oder BIOSse von Mainboards können bislang nur mit 512 Byte Sektoren umgehen. Wie sich das Mit (U)EFI Mainboard-Firmwares verhält, habe ich keine Info, die findet man jedoch auf normalen Mainboards nur sehr selten, bei Serverboards ist das ganze mittlerweile fast Standard . ich gehe allerdings davon aus, daß es hier genau das gleiche ist, wie bei den Raidcontrollern, nämlich Fehlanzeige bzw. offiziell nicht supported.

Naja, wir wissen nicht, ob 512e-Platten Performance kosten. Wir gehen höchstens davon aus, weil wir denken, dass allgemein Emulation vs. Nativ immer kosten muss.

Das sagt doch schon die einfache mathematische Addition der Einzelvorgänge von "Read / Modify / Write", das muss länger dauern als einfach nur "Write", nämlich mindestens eine Plattenumdrehung während der das Modify geschieht.

Das Performancesteigerungen der letzten 25 Jahre sind zum grössten Teil auf die immer höheren Datendichten zurückzuführen welche durch den technologischen Fortschritt möglich wurden.
Heutige Festplatten sind allesamt ausreichend schnell für z.B. Videostreaming / -mitschnitt und ähnliches (selbst die 2,5" Platten mit 4500 U/min) - ich habe mit einer für damalige Verhältnisse schnellen 540 MB Platte von Seagate angefangen ..... wat für ne lahme Krücke nach heutigen Gesichtspunkten ;-)

ciao
Lothar
 
Zuletzt bearbeitet:
Wenn ich eine 4k-Sektoren Platte (unter Win7 formatiert) extern an einem XP Rechner Betreibe - habe ich Nachteile?
 
Im weitesten Sinne Ja!
OK. Übrigens unterstützt Windows selber bisher in keiner Version native 4K-Platten. Aber die gibt es ja auch noch nicht :)


Das sagt doch schon die einfache mathematische Addition der Einzelvorgänge von "Read / Modify / Write", das muss länger dauern als einfach nur "Write", nämlich mindestens eine Plattenumdrehung während der das Modify geschieht.
Ein RMW-Zyklus ist teuer, ja. Die Frage ist nur, ob es dazu kommt.

Streng genommen gibt es das Problem auch bei 512n, wenn weniger als 512 Byte geschrieben werden müssten. Durch Padding löst Windows beispielsweise das Problem: Wenn ich nur 400 Bytes zum Schreiben habe, füllt Windows mit 112 Bytes auf. So kann der physikalische Sektor direkt geschrieben werden.

Gleiches macht auf der Hotfix, wodurch Windows Vista/7 mit 4K-Platten umgehen können. Statt auf 512 Byte aufzufüllen, wird nun eben auf 4096 Byte aufgefüllt. Aber nur dann, wenn die 512e Platte eben eine physikalische Sektorengröße von 4096 zurückmeldet. Macht sie es nicht, bzw. unterstützt der Treiber des Storage-Controllers diese Abfrage nicht, kann Windows hier nicht eingreifen.

Programme die sich selber darum kümmern, wie geschrieben wird und nicht auf entsprechende APIs zurückgreifen (hierfür gibt es durchaus legitime Gründe), müssen natürlich wie Windows auch 4K-ready gemacht werden. Andernfalls werden diese Anwendung langsam laufen...

Heutige Festplatten sind allesamt ausreichend schnell für z.B. Videostreaming / -mitschnitt und ähnliches (selbst die 2,5" Platten mit 4500 U/min) - ich habe mit einer für damalige Verhältnisse schnellen 540 MB Platte von Seagate angefangen ..... wat für ne lahme Krücke nach heutigen Gesichtspunkten ;-)
Hehe - ja! Aber damals fehlten die Anwendungen und es war in Ordnung.
Wo du schon A/V ansprichst: Derzeit sind wir bei 720/1080p. Passt. Aber 4096p wird bereits von YouTube unterstützt :asthanos:
 
Wo du schon A/V ansprichst: Derzeit sind wir bei 720/1080p. Passt. Aber 4096p wird bereits von YouTube unterstützt

OT:
Womit wir denn wieder bei 4K wären - Seltsame Paralellitäten der Begrifflichkeiten, die ersten Display für 4K sind auch schon vorgestellt worden. Wann 4K Einzug in die Wohnzimmer hält wage ich mal keine Prognose - bislang stehen noch sehr viele Röhren (PAL = 720*578) in den Wohnzimmern.
\OT

ciao
Lothar
 
Zuletzt bearbeitet:
Nochmal zum Verständnis: Wenn ich eine 4kb Platte unter XP nutzen möchte, dann muss ich diese einfach nur entweder mit W7 formatieren oder das Alignment manuell richtig setzten (wie bei einer ssd)?
 
Ah, danke.
Und des Alignment kann ich dann auch einfach mit AS SSD überprüfen?
 
guten abend

habe mir heute eine WD20EARX 2 TB bestellt.

sollte ich was beim formatieren beachten oder kann ich sie einfach mit windows 7 fomatieren und fertig?
 
Im Moment hab ich 3x Samsung F4 an einem aktuellen LSI, Raid5. Demnächst möchte ich noch eine vierte Platte hinzufügen.

Nach der Theorie dieses Threads müsste das Raid dann schneller sein, weil gilt: Stripesize / Anzahl der Platten = Vielfaches von 4k

Richtig?
 
Nein. Du hast die 4K-Problematik nicht verstanden.

Das Problem ist, dass die Laufwerke zwar intern damit arbeiten, nach außen aber eben nicht. Somit kann der theoretische Vorteil nicht genutzt werden. Gerade diese 512e Platten stehen bei RAID im Verdacht für Performance-Probleme verantwortlich zu sein, weil:

Richtige 512er Platte:
Betriebssystem gibt Daten an Platte. Wenn neue Daten, wartet die Platte, bis ein physikalischer Sektor voll ist. Dann schreibt die Platte ihn.
Bei geänderten Daten veränderte der Controller diese Bits und schreibt den phy. Sektor.

Richtige 4K Platte:
Betriebssystem gibt Daten an Platte. Das System weiß hier von der 4K-Fähigkeit und reicht entsprechende größere Blöcke (nicht verwechseln mit Clustern!) weiter. Es verhält sich wie bei der nativen 512er Platte.

Falsche 512 Platte aka 512e:
Die Platte gibt sich als 512er Platte nach außen erkennbar. Das System gibt somit 512er Blöcke weiter. Die Einzelplatte würde jetzt aber warten, bis eben ein phys. Sektor voll ist... also warten bis sie 4K zu schreiben hat. Kein Problem - das regelt der Cache. Hier hilft die Ausrichtung.
Bei Änderungen hingegen muss leider der gesamte 4K Sektor gelesen, geändert und neu geschrieben werden.

Ist die Platte jetzt aber in einem Array, dann kann sie eben nicht warten, bis sie genug Daten für einen phy. Sektor zusammen hat. Der RAID-Controller weist die Platte eben direkt an zu schreiben, weil er von 512 ausgeht... wenn jetzt bspw. 8 512er Sektoren an das 4K Laufwerk gehen, sendet der RAID Controller 8x den Befehl zu schreiben... ineffektiv... denn bei jedem weiteren Schreibvorgang muss die Platte eben den phy. Sektor erst wieder einlesen... veärndert jetzt den nächsten 512er Block... schreibt wieder den kompletten Sektor...
 
Aber das müssen die Platten doch in beiden Fällen machen, egal obs jetzt drei oder vier Platten im Array sind.
Dass das Raid schneller wird wenn eine Nutzplatte mehr dazu kommt, ist klar. Aber wie mueder_joe geschrieben hat, hat die Anzahl der Festplatten noch einen andren Einfluss.
Wo ist der günstiger, bei drei oder vier Platten?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh