WD20EARS - (Soft)Raid5 mit SB750 - 4K Sektoren

Hallo an Alle,

nachdem ich feststellen musste, dass Windows 7 kein Raid5 beherrscht und es noch nicht (wie damals bei Windows XP) die Möglichkeit gibt, dieses Feature über Umwege zu erhalten, bin ich nun beim Softraid der Southbridge gelandet.

Ich habe natürlich direkt ein bisschen gebencht und bin mit der Schreibrate von 70MB/s nicht sonderlich zufrieden (ich dachte da geht mehr?).

Natürlich fiel der Verdacht direkt auf das 4-K Sektorproblem.
Es heißt ja, das sei für Windows 7 kein Problem. Ich kenne mich leider aber nicht gut genug aus, um zu wissen, ob das auch für ein Raid-Volume gilt.

Die Frage lässt sich also reduzieren auf: Kann die SB750 im Raid5 Modus mit 4K-Sektor-HDDs umgehen und richtig darauf schreiben?

Was ich testweise gerade gemacht hab, bei allen HDDs einen Jumper auf 7-8 gesetzt. Hiermiet emuliert die Festplatte den ersten Sektor nicht bei 63, sondern 64. Dies soll ein Trick sein, um eine geeignete Anfangsadresse zu erhalten (alles von mir als Laie wiedergegeben).
Die Ergebnisse sind allerdings ernüchternd, laut Benchmark war es vorher schneller (Schreibgeschwindigkeit jetzt nur noch die Hälfte).

Die 70MB/s (sequentielles Schreiben) sind also das Maximum?


Hoffe, es kennt sich da jemand besser aus.

Gruß
Johannes


edit: Es geht um 4 Festplatten im Raid5 Verbund

du hast bestimmt die 4platter ears?..
die is etwas langsamer..

wieviele platten?

imm 3 oder 5 platten und mach16k stripe und windows 64 k cluster size.

https://www.computerbase.de/forum/threads/16-w-core-i3-530-komplettsystem-standard-v.685231/

cadaver112 schrieb:

du hast bestimmt die 4platter ears?..
die is etwas langsamer..

Zum Vergrößern anklicken....

Steht doch in der Überschrift, dass er eine WD20EARS hat. KLICK

Gruß, Eisholz

@Eisholz:
Wobei es die EARS in 2 Ausführungen gibt, auch wenn das bei WD alles unter einem Label läuft. Ü-Ei halt.
Die ältere Version nutzt 4 Magnetscheiben mit je 500GB, die neuere 3 Scheiben á 667GB.

die WD20EARS gibt es aber neuerdings auch mit 3 plattern.
WD hat aber keine neue Produktnummer vergeben, daher ist es Glücksspiel welche man erwischt.

das aht aber meiner Meinung nach weniger mit seinem Problem zu tun.

Softwareraid (also Fake Raid) ist einfachnicht schneller... D mußt Du schon Geld für einen vernünftigen Controller in die Hand nehmen....

Krautmaster schrieb:

wieviele platten?

imm 3 oder 5 platten und mach16k stripe und windows 64 k cluster size.

Ergänzung (5. August 2010)

https://www.computerbase.de/forum/threads/16-w-core-i3-530-komplettsystem-standard-v.685231/

Zum Vergrößern anklicken....

Leider bringt mir diese Antwort nicht viel. Es handelt sich nicht um den von mir verwendeten Chipsatz, und wenn mich nicht alles täuscht, kann ich 16K bei der Stripesize garnicht einstellen.
Warum ich gerade 3 oder 5 und nicht 4 HDDs verwenden soll, verrätst du mir auch nicht, und im von dir verlinkten Thread (der mir übrigens wegen der PICO PSU Netzteile bekannt war) finde ich keine solche Information.

edit: gerade gefunden:
"Mögliche Streifengrößen für Datenblöcke sind 64 und 128 KB [...]"

Nitewing schrieb:

Softwareraid (also Fake Raid) ist einfachnicht schneller... D mußt Du schon Geld für einen vernünftigen Controller in die Hand nehmen....

Zum Vergrößern anklicken....

Habe ich mir fast gedacht. So tragisch ist es allerdings auch nicht.
Von Hardware-Raid habe ich Abstand genommen, da mir entsprechende Enterprise Platten einfach zu teuer sind - so dringend brauche ich es nicht schneller.

Ich wollte lediglich wissen, was es so mit den 4K-Sektoren im Zusammenhang mit dem SB750-Raid auf sich hat - die bisherigen Poster sagen hierzu leider nichts.



Was die Anzahl der Platter angeht: Ich kann leider nicht reinschauen :-)

florian. schrieb:

die WD20EARS gibt es aber neuerdings auch mit 3 plattern.
WD hat aber keine neue Produktnummer vergeben, daher ist es Glücksspiel welche man erwischt.

das aht aber meiner Meinung nach weniger mit seinem Problem zu tun.

Zum Vergrößern anklicken....

Aha, das war mir neu; ich bin davon ausgegangen, dass unterschiedliche Platten auch unterschiedliche Typenbezeichnung bekommen.

Gruß, Eisholz

Ein HArdware Raid benötigt nicht zwangsläufig Enterprise Platten. Der Controller ist das entscheidende Element...

...dann muss ich mich allerdings mit TLER rumschlagen, was meines Wissens bei den aktuellen WD Festplatten nicht mehr abschaltbar ist.

Hö?
TLER sorgt doch gerade bei den RE-Platten dafür, dass bei einem Fehler innerhalb einer Zeitspanne abgebrochen wird sodass der Controller eingreifen kann und nicht die Platte aus dem RAID kantet, oder irre ich da jetzt?

Bei Consumerplatten steht der Wert aber unveränderbar so hoch, dass der Controller die Platte aus dem Verbund schmeißt, weil sie so lange nicht antwortet bzw abbricht.

Okay, dann hab' ich das missverstanden...
Ja, dann ist das in der Tat ungünstig.

Da die Schreibrate wirklich unter aller Sau ist, werde ich das ganze erstmal seinlassen.
Es sei denn, es schreibt noch jemand sowas wie:
"Es liegt an den 4K Sektoren und die Lösung ist: [...]".

Schade - um ehrlich zu sein, am meisten nervt es mich, Daten auf Festplatten hin und herzuschieben (wenn voll) und trotzdem den Überblick zu behalten.

Raid5 sollte für mich eigentilch nur ein etwas besseres JBOD sein.

TLER ist absolut kein Problem wenn die Platte nicht wirklich einen Hau weg hat so dass sie eine Anfrage nicht in bestimmter Zeit bearbeiten kann. Es ist nicht so das Consumer Platten andauernd aus irgendwelchen Arrays droppen.

Ich hab ein Raid 5 aus 8 WD Green Platten an einem PCIe SAS Hardware Raidcontroller und weder Probleme mit TLER noch Load Cycle Counts ohne was an den Platten rumzufummeln.

Ein Fake Raid ist halt wirklich lahm beim schreiben. Da kann man nicht viel machen ausser Linux zu nutzen (ist schon wesentlich besser als Windows oder Fake Raid basierende Arrays aber bei multiplen Zugriffen auch wieder lahm)

Über den Intel Write Back Cache müssen wir uns nicht unterhalten. Ist nichts neues das die Aktivierung dessen sämmtliche Benchmark Tools zu absolut Weltfremden Werten verführt weil hier der Systemspeicher ganz groß genutzt wird.

Es sei denn, es schreibt noch jemand sowas wie:
"Es liegt an den 4K Sektoren und die Lösung ist: [...]".

Zum Vergrößern anklicken....

Damit kann ich leider nicht dienen, aber wer rechnen kann, ist klar im Vorteil.

- unter Win7 vorgenommene Partitionierung ist an 1MiB-Grenzen ausgelegt(2048 Sektor Alignment bei 512B Sektorsize)- somit ist der Jumper kontraproduktiv.
- die NTFS-Clustersize kann von 512B bis 64KiB (4KiB default) eingestellt werden(1-128, default 8 Sektoren bei 512B Sektorsize)
- Zugriffe auf ein NTFS-Filesystem erfolgen im Normalfall in Größenordnungen von der Clustersize bis zu 64K, unabhängig von der Clustersize, für Daten (1/default 8 bis128 Sektoren bei Sektorsize 512B),
- schreibende Metadatenzugriffe wie $MFT-Verzeichniseinträge, $Bitmap-Platzverwaltung oft auch nur 1 Sektor mit Sektorsize 512B

- die Stripesize ist bei Intel von 4K bis 128K, bei AMD anscheinend nur 64K und 128K wählbar
- die Datenkapazität eines Stripesets=Stripesize*(Memberplattenzahl-1)
- bei I/Os die nicht an der Datenkapazität eines Stripesets aligned sind, muss vor dem Schreiben zuerst zur Bildung der Parity von anderen Platten gelesen werden

"günstige" Definition eines onboard-RAID5 für hohe Schreibperformance wären daher
- Clustersize 64K, Stripesize 32K, 3 Memberplatten(nur mit Intel erreichbar)
- Clustersize 64K, Stripesize 16K, 5 Memberplatten(nur mit Intel erreichbar)
weil bei einem I/O über ein gesamtes Stripeset, aligned in der Größe des Stripesets, der Lesezugriff zur Paritybildung entfällt
Genau aus diesem Grund erfolgt im obigen ATTO der sprunghafte Anstieg der Schreibleistung bei I/Os mit 64K

in allen anderen Fällen leidet die Performance beim Schreiben an den notwendigen vorherigen Lesezugriffen für die Paritybildung (zusätzlich zu den nicht-4K-aligned Schreibzugriffen auf die Metadaten je Datei, welche eine Verzögerung der Dauer einer kompletten Umdrehung verursachen) die sich bei Verarbeitung von vielen kleinen Dateien bemerkbar macht.

Die sektorweisen $MFT- und $Bitmap-Schreibzugriffe und weniger als 8 Sektoren großer Dateien sind es übrigens, welche in Benchmarktests von AFT(Advanced Format Technology)-Platten die von allen Testern unerklärbaren mysteriösen Einbrüche bei WinRAR-Tests verursachen

Die hier "erbenchten" Leistungswerte lassen sich natürlich auch rechenrisch vorhersagen (und damit auch nachvollziehen)

Humptidumpti schrieb:

[...]
Über den Intel Write Back Cache müssen wir uns nicht unterhalten. Ist nichts neues das die Aktivierung dessen sämmtliche Benchmark Tools zu absolut Weltfremden Werten verführt weil hier der Systemspeicher ganz groß genutzt wird.

Zum Vergrößern anklicken....

Habe ich nicht gewusst, dass da auf gewisse Art und Weise gepfuscht wird, da werd ich mich mal einlesen.

Ernst@at schrieb:

Damit kann ich leider nicht dienen, aber wer rechnen kann, ist klar im Vorteil.

[...]

Zum Vergrößern anklicken....

Oh oh, ich glaub ich leg mich nochmal hin und Versuch das in zwei Stunden nochmal nachzuvollziehen. Bis dahin

Was ich schonmal sagen kann: Zumindest für mich ist es nicht ganz klar, dass es kontraproduktiv ist!
Schließlich übernimmt die Partititioniernug im eigentlichen Sinne hier nicht Windows, sondern vom "Fake-Raid" wird sowas wie eine Virtuelle Festplatte angeboten. Woher weiß ich, dass dieser nicht überall ab Sektor 63 (oder wie auch immer, auf jeden Fall nicht richtig für 4K Sektoren) vom Controller abgegriffen wird?
Macht es Windows 7 dann dennoch richtig?

Sorry, falls ich hier hartnäckig bleibe - ich würde dei Hintergründe gerne verstehen.

Nitewing schrieb:

Softwareraid (also Fake Raid) ist einfachnicht schneller... Da muss man schon Geld für einen vernünftigen Controller in die Hand nehmen....

Zum Vergrößern anklicken....

naja, das ist quatsch. Controller fressen meist unnötig viel strom und sind oft anfälliger als heutige Mainboards. Ein Windows Raid ist zudem einfach umziehbar.

Übrigens habe ich egal ob Nvidia, Windows oder Intelraid vergleichbare Werte. >70mb/s ist ganz einfach schon durch die plattenzahl drin. da werdern die ears keinen unterschied machen.

da gilt:

Wichtig:

Mit Abstand die beste Performance liefert:

ClusterSize = StripSize * (Plattenzahl -1)

-> Raid 5 mit 5 Platten
64k = 16k *(5-1)

-> Raid 5 mit 3 Platten
64k = 32k* (3-1)

Performance Sprung durch oben genannte Konfiguration:
27-40 MB/s write -> 240MB/s write !!

Zum Vergrößern anklicken....

https://www.computerbase.de/forum/t...rschluesselt-raid5-performance-how-to.663647/

Das Intel raid kann jedoch mehr als das Windows und auch mehr als ein billiger Controller:

Es geht folgendes: Bei allen Lösungen bleiben die Daten natürlich erhalten:

Kein Raid -> Raid 1

Raid 1 -> Raid5

Raid 5 -> Raid5 mit mehr Platten

Raid 5 Größe verändern (zB von 2 GB auf 4000 GB ohne Platten hinzuzufügen)

Zum Vergrößern anklicken....

zudem kann ein intel und Windows raid die Platten schlafen legen, was meines wissen nur ein Adaptec 5XXX kann.
Aber kauf ma nen gescheiten Controller... da kannste gleich mal Plattenzahl + Speicher verdoppeln und nen 1:1 Backup ziehen ^^

Edit:

Seid ihr sicher, dass die Sektoren derart komplizierten Eingriff benötigen?

Ernst@at schrieb:

- die Stripesize ist bei Intel von 4K bis 128K, bei AMD anscheinend nur 64K und 128K wählbar
- die Datenkapazität eines Stripesets=Stripesize*(Memberplattenzahl-1)
- bei I/Os die nicht an der Datenkapazität eines Stripesets aligned sind, muss vor dem Schreiben zuerst zur Bildung der Parity von anderen Platten gelesen werden

"günstige" Definition eines onboard-RAID5 für hohe Schreibperformance wären daher
- Clustersize 64K, Stripesize 32K, 3 Memberplatten(nur mit Intel erreichbar)
- Clustersize 64K, Stripesize 16K, 5 Memberplatten(nur mit Intel erreichbar)
weil bei einem I/O über ein gesamtes Stripeset, aligned in der Größe des Stripesets, der Lesezugriff zur Paritybildung entfällt
Genau aus diesem Grund erfolgt im obigen ATTO der sprunghafte Anstieg der Schreibleistung bei I/Os mit 64K

Zum Vergrößern anklicken....

korrekt

lamer11 schrieb:

"Es liegt an den 4K Sektoren und die Lösung ist: [...]".
.

Zum Vergrößern anklicken....

wie gesagt, ich glaube nicht, dass es daran liegt. Es liegt schlicht an der Raid5 Konfig.

Formatier einfach deine Platte mal auf 64k "größe der Zuordungseinheiten"

Danke nochmal für die Infos, ich beginne zu verstehen. Das Raid mit der SB750 lässt sich übrigens auch migrieren, man kann von 1->2 (Mirror)->3 (Raid5) ->4 (Raid5).. ohne Probleme, ich glaube man kann auch nacheinander die HDDs durch größere ersetzen.

Ich scheitere offenbar also auch an der Unflexibilität der SB750, ich kann ja gar keine Stripesize unter 64KB wählen. Leider kommt eine 5. HDD auch nicht in Frage, da ganz einfach mein Mainboard zu ist (SDD + ODD + 4HDD, habe bloß 6 SATA, naja, könnte Notfalls natürlich nen IDE ODD besorgen).

Und auch da würde ich an der Stripesize scheitern, schließlich kann ich nicht mit einer Clustergröße von 256K formatieren ;-)

Das von dir erstellte und jetzt verlinkte Thema ist sehr aufschlüssig! Verstehe jetzt deine Bemerkung vom Anfang.

Achja, und CPU Last sollte doch heute, in Zeiten von vier Kernen mit >3GHz und 8GB Ram, eigentlich keine Rolle mehr spielen. Zumindest habe ich nicht beobachtet, wie ein Kern unter Vollast ging, als ich auf das Array kopierte.


edit1: Warum werden eigentlich dann Hardware-Raid-Controller (ich kenne einigermaßen gut die 9650 von 3Ware) mit einer geraden Anzahl von Schnittstellen ausgelifert. Optimalerweise müsste man ja dann einen Port freilassen. Oder spielt es dort keine Rolle mehr?
Dieser Thread hier ist leider auch im Sand verlaufen, versprach interessant zu sein: http://www.overclockers.at/storage_memory/wd20ears_in_hardware_raid_217145