Onboard Raid Controller - Raid 5 >100 MB/s WRITE

Seite 1 von 4 - Forum: Storage & Memory auf overclockers.at

URL: https://www.overclockers.at/storage-memory/onboard_raid_controller_raid_5_100_mb_s_write_205538/page_1 - zur Vollversion wechseln!

master blue schrieb am 07.03.2009 um 15:19

Hallo!

In diesem Thread geht es darum, wie man aus einem Raid 5 Array eines Onboard Controllers mehr als 100 MB/s beim Schreiben herausholt.
Begonnen hat das ganze hier. Fast sämtliche Infos beziehen sich auf einen Thread von www.storagereview.com des Users qasdfdsaq.

Wie schnell ist ein Raid 5 Array eines Onboard Controllers (nForce oder Intel) im Normalfall:
Windows XP / Server 2003: ~20-30 MB/s
Vista / Server 2008: ~30-40 MB/s

Warum gibt es bei den Betriebssystemen solche Unterschiede:
Windows XP und Server 2003 (ist XP-basierend) legen den Start einer Partition (engl. partition offset) auf 32,5 kB (Sektor 63), Vista und Server 2008 (ist Vista-basierend) legen den Start auf 1024 kb.
Um den weiteren Zusammenhang zu verstehen, müssen ein paar Begriffe erklärt werden.

Array abhängige Werte:

stripe width:
Anzahl der verwendeten Festplatten - 1 (Diesen Wert kann man nur mit unterschiedlicher Festplattenanzahl beeinflussen.)
stripe size: siehe Wikipedia
Für ein Raid 5 mit 3 Festplatten empfehlen sich 32k, mit 5 Festplatte 16k.

Betriebssystem abhängige Werte / Art der Formatierung:

I/O Block Size:
In welchen Größen das OS die Daten zur Festplatte liefert. Dieser Wert kann nicht verändert werden.
Windows XP / Server 2003: 64 kB
Vista / Server 2008: 1-8 MB
cluster size:
Das ist die Größe der Blöcke, wie sie die Festplatte auf die Platter schreibt. Der Windows Standard-Wert hierfür sind 4k. Windows XP / Server 2003 lassen Formatierungen bis 4k zu (darüber hinaus benötigt man ein Partitionierungs Tool wie Partition Magic), Vista / Server 2008 ermöglichen von sich aus Formatierungen bis 64k.
In der cluster size liegt u.a. auch der Schlüssel für das schnelle Schreiben. Empfehlenswert sind 32 und 64k. Befindet sich auch das OS am Array, so muss diese Partition mit der Standard cluster size betrieben werden (denke ich jedenfalls), wodurch man mit der Standard Schreibrate vorlieb nehmen muss.

Je größer die cluster und stripe size desto höher der Datendurchsatz, jedoch desto höher die Zugriffszeit. Cluster size und stripe size muss man genaugenommen für jedes Raid itterativ bestimmen, heißt, man muss div. Kombinationen ausprobieren. Das ist aber eine recht langwierige Arbeit, daher geht man am besten von 32 oder 64k für beide aus. Entscheidend ist übrigens auch die im Array verwendete Dateigröße. Sind die Dateien recht groß (Images,...) sind größere Werte besser.

Genug mit den ganzen Fachbegriffen, zurück zur eigentlichen Frage. Die Startposition einer Partition muss durch die stripe width und stripe size (bzw. ein Vielfaches davon) ganzzahlig dividierbar sein, sonst hat der Controller mehr mit dem Zerstückeln der Daten zu tun, wodurch die Performance extrem leidet. Man erkennt sofort, dass 32,5 kb (Sektor 63) von Windows XP / Server 2003 einfach kein vielfaches der stripe width oder stripe size ist, hingegen die 1024 kb von Vista / Server 2008 sehr wohl.

Was ist nun zu tun - Schritt für Schritt:

Partition offset:
Windows XP / Server 2003: Der Startsektor muss auf einen vielfachen Wert der stripe width und stripe size verändert werden (z.B. 32, 64, 128,...).
Vista / Server 2008: Hier ist nichts zu ändern, 1024 passt wunderbar.
stripe size:
Wird beim erstellen des Arrays festgelegt.
Raid 5 mit 3 Festplatten am besten 32k, bei 5 16k.
cluster size:
Wird beim Formatieren der Partitionen festgelegt. Am besten zwischen 32 und 64k wählen.
Windows-Einstellungen:
Gerätemanager -> Eigenschaften des Arrays -> Richtlinien -> "Schreibcache auf dem Datenträger aktivieren" und "Erhöhte Leistung aktivieren" anhaken.

"Schreibcache auf dem Datenträger aktivieren": Aktiviert den Festplatten-Cache. Ist standardmäßig aktiviert.
"Erhöhte Leistung aktivieren": Fragt mich nicht, was diese Option genau macht. Ich vermute, dass bei Datenraten, die über der Schreibrate liegen, die Daten in den RAM gecached werden. Werde das noch versuchen zu verifizieren.

Zu guter letzt gibt es natürlich auch noch Werte:
Mein System:
Intel Celeron 430
MSI P6NGM-FD (nForce 630i)
3x WD 500 GB (WD5000AAKS) im Raid 5 (stripe size = 32, cluster size = 32)
Windows Server 2008

System-Partition C: cluster size = 4k

Daten-Partition D: cluster size = 32k

Fragen, Anregungen, Korrekturen oder Ergänzungen bitte posten.

Römi schrieb am 07.03.2009 um 18:22

Nur ein paar anmerkungen...

NTFS Clustersize umstellen ist normal nicht nötig. Man verschwendet mit einer höheren Clustersize auch plattenplatz - sollte man auch bedenken. Bei ntfs mit einer Clustersize > 4k wird auch keine "file compression" unterstützt - soweit ich gelesen habe.

Generell denke ich wird man bei einem "guten" Controller nicht allzuviel damit herausholen können - bei denen schafft man auch ohne besondere Optimierungen gute Schreibwerte.

Ich würde davon abraten Onboard controller für Raid 5 zu verwenden wenn die daten darauf sicher sein sollen. Ich hab mich vor einiger Zeit etwas mit dem ICHR gespielt und war recht enttäuscht - war nicht besonders schnell; und auch dass er nach einem Absturz oder Stromverlusst/Reset das array rebuilden muss ist imo eher bedenklich.

master blue schrieb am 08.03.2009 um 04:52

Zitat
NTFS Clustersize umstellen ist normal nicht nötig.

bei externen controllern nicht nein, die holen selbst schon viel heraus. hat aber auch seinen preis.

Zitat
Man verschwendet mit einer höheren Clustersize auch plattenplatz

jop, kommt auf die im raid verwendete dateigröße an. kann man aber glaub ich vernachlässigen, außer man verwendet viele sehr kleine (<<cluster size) dateien.

Zitat
Ich würde davon abraten Onboard controller für Raid 5 zu verwenden wenn die daten darauf sicher sein sollen. Ich hab mich vor einiger Zeit etwas mit dem ICHR gespielt und war recht enttäuscht - war nicht besonders schnell; und auch dass er nach einem Absturz oder Stromverlusst/Reset das array rebuilden muss ist imo eher bedenklich.

ich bin seitdem die schreibrate auch passt voll zufrieden. mit meinem nforce onboard controller hatte ich auch nie schwierigkeiten. der pc hängt an einer usv, die würde ich sowieso jedem empfehlen. es braucht ja nur was im cache liegen und weg is es.
erwähnen sollte man noch, dass die berechnung vom paritätsbit schon etwas die cpu belastet, was bei einem externen controller wegfällt. bei mir wird der celeron 630 zu etwa 40% ausgelastet.

EG schrieb am 08.03.2009 um 17:21

Sehr schöne Arbeit! Danke für diesen interessanten "Artikel.

fresserettich schrieb am 08.03.2009 um 19:14

weiß nicht bin kein fan von onboard raid aber trotzdem danke für den artikel
bei mir werkelt halt das raid (via sw-raid unter linux) in einem eigenen rechner

edit: in zeiten wo ein dual-core standard ist, wir wohl die cpu last nicht mehr das große problem sein

Templer schrieb am 09.03.2009 um 23:03

Zitat
"Erhöhte Leistung aktivieren": Fragt mich nicht, was diese Option genau macht. Ich vermute, dass bei Datenraten, die über der Schreibrate liegen, die Daten in den RAM gecached werden. Werde das noch versuchen zu verifizieren.

Aber das ist doch klar das du über 100mb/s schreiben hin bekommst mit Writeback Cache oder sehe ich da was falsch?

master blue schrieb am 10.03.2009 um 00:33

Zitat von Templer
Aber das ist doch klar das du über 100mb/s schreiben hin bekommst mit Writeback Cache oder sehe ich da was falsch?

ich hab mich auf dein schlagwort "wirteback cache" hier bisschen dazu eingelesen. so wirklich verstehe ich aber nicht, warum es soeinen boost gibt. bei write-through wird scheinbar alles über den RAM geschleust, nur warum ist dieser vorgang soeine bremse? RAM ist ja nicht gerade schlecht angebunden.
ohne entsprechende cluster size UND der aktivierten option bekomm ich keine >100mb/s, fehlt eines der beiden, gibts nur rund 30-40mb/s (siehe benchmark der sys partition). an der auslastung des RAMs ändert sich bei schreibvorgängen kaum was, zwischen 5 und 10% bei 1gb speicher.

Römi schrieb am 10.03.2009 um 15:16

Dieses Verhalten ist imo Controller-spezifisch.
Normalerweise schaltet man am controller den cache ein und das wars.

Smut schrieb am 10.03.2009 um 15:27

der punkt ist halt, dass du keine 100 MB schreibleistung hast - du umgehst den flaschenhals (xor berechnung) mittels cache.

master blue schrieb am 10.03.2009 um 15:41

Zitat von Smut
der punkt ist halt, dass du keine 100 MB schreibleistung hast - du umgehst den flaschenhals (xor berechnung) mittels cache.

versteh ich nicht, bitte um erklärung.

Smut schrieb am 10.03.2009 um 15:49

was hättest du sonst vom read/write und advanced performance erwarted?
die daten werden vom OS entgegengenommen, aber nicht in dieser geschwindigkeit aufs array geschrieben. atto benchmark reagiert auf den erhöhten cache. weshalb durch die blockgröße diese performancesteigerung im vergleich zum c drive erzielt wird ist eine andere sache. das c laufwerk wird auf jeden fall aufgrund OS-zugriffe und speicherauslastung unterbewertet.

meine grundaussage bleibt: du schreibst keine 100mb/sec aufs array.

master blue schrieb am 10.03.2009 um 20:21

Zitat von Smut
was hättest du sonst vom read/write und advanced performance erwarted?
die daten werden vom OS entgegengenommen, aber nicht in dieser geschwindigkeit aufs array geschrieben. atto benchmark reagiert auf den erhöhten cache. weshalb durch die blockgröße diese performancesteigerung im vergleich zum c drive erzielt wird ist eine andere sache. das c laufwerk wird auf jeden fall aufgrund OS-zugriffe und speicherauslastung unterbewertet.

meine grundaussage bleibt: du schreibst keine 100mb/sec aufs array.

ich hab bis templers post mit der "erhöhten leistung aktivieren" keinen plan gehabt, was diese option eigentlich ändert. die beschreibung ist ja auch unter aller sau.
heißt das, es würden andere werte herauskommen, wenn atto auf wwi 5gb testen würde statt 256mb?

Smut schrieb am 10.03.2009 um 20:28

das hängt dann von effektiver schreibleistung und cachegröße ab.
ich würde den cache einfach komplett deaktivieren - so wie für ein raid üblich. weil wennst da ein paar hundert MB im RAM hast während er abstürzt, kannst dir das RAID5 zerschießen.

hier übrigens eine info zu "enhance performance":
http://technet.microsoft.com/de-de/...nfidential.aspx

-> das von MS als leistungssteigerung verkaufte feature ******t einfach nur auf integrität - kein wunder, dass man damit schneller wird

edit: auf den atto benchmark bezogen heißt das soviel, windows teilt dem einfach mit was es gerade will und dass es dadurch tatsächlich schneller wird ist scheinbar (lt. storagereview) auch bewiesen. allerdings zu welchem preis?

master blue schrieb am 10.03.2009 um 20:39

Zitat von Smut
das hängt dann von effektiver schreibleistung und cachegröße ab.
ich würde den cache einfach komplett deaktivieren - so wie für ein raid üblich. weil wennst da ein paar hundert MB im RAM hast während er abstürzt, kannst dir das RAID5 zerschießen.

hier übrigens eine info zu "enhance performance":
http://technet.microsoft.com/de-de/...nfidential.aspx

-> das von MS als leistungssteigerung verkaufte feature ******t einfach nur auf integrität - kein wunder, dass man damit schneller wird

d.h. ich suche mir am besten einen datentäger/pc, der mir >100mb/s liefern kann und beobachte während eines transfers die füllrate des RAMs.
das raid hängt an einer usv, da mach ich mir keine sorgen.

master blue schrieb am 10.03.2009 um 20:41

Zitat
allerdings zu welchem preis?

zum preis einer usv.

ups, sollte eigentlich ein edit sein.