Raid5 20mb/s Schreiben ?

[m0p3d]

Ist das normal ich hab am ein und selben Pc beim Mirroring Datenraten von 80mb/s jetzt hab ich formatiert und nen Raid 5 eingerichtet und jetzt schreib ich maximal mit 20 mb/s kommt das durchs Raid oder ist das evtl was anderes ?

Controler ist Nvidia 8200

 

[Schlingel_INV]

des kommt durchs raid5 an nem software-raid

 

[kalgani]

des kommt durchs raid5 an nem software-raid

mehr muss da nicht mehr gesagt werden.

 

[m0p3d]

Is das so rechenintensiv oder was auch immer ? Bzw wer erledigt das is das Prozessorlastig oder kann man da nicht nachhelfen

 

[M.D. Geist]

XOR Berechnungspower des controllers...

 

[m0p3d]

Was kann man mit den Controlern von Highpoint für 170-200 € an Schreibgeschwindigkeit erziehlen ?

 

[ic3m4n2005]

Sofern der Controller nen eigenen XOR Prozessor hat ja.
In dem Preisbereich bietet sich der Dell Perc 5i über ebay an.

 

[BlackGhost]

Sammelthread beachten!

 

[7oby]

Controler ist Nvidia 8200

Bei dem liegst Du da im Bereich des zu Erwartenden:

http://www.tomshardware.com/de/P45-Intel-Chipsatz,testberichte-240091-19.html

 

[Platja d Aro]

Wieso um alles in der Welt ist ein dedicated Array bei Intel so dermaßen langsam, dass man es gar nicht verwenden braucht?!

Die Schreib und Lesewerte wären ja ganz ok...

Aber sobald das Ding ausfällt geht die sch..... los

Weiß jemand warum das so ist?

 

[KeinNameFrei]

Was soll denn in dem Bild "degraded" heißen...?

 

[ic3m4n2005]

Bei Raid 5 darf eine Platte ausfallen, wenn das passiert ist es degraded, man kann es aber noch weiter nutzen (sollte man aber net ).

 

[7oby]

Wieso um alles in der Welt ist ein degraded Array bei Intel so dermaßen langsam, dass man es gar nicht verwenden braucht?!

Das wüsst' ich auch gerne. Einen technischen Grund dafür gibt's nämlich nicht. Das bißchen XOR darüber lacht eine 2+ GHz CPU. Insbesondere, da ich im Linux-Quellcode zum mdadm nachgeschaut habe u. SoftRAIDs das auch in den 128Bit SSE Registern rechnen. In Truecrypt ist ja ebenfalls ein Benchmark enthalten. Diese Algorithmen sind komplexer u. enthalten am Ende des Decoders ebenfalls ein XOR. Hohe Übertragungsraten sind auch damit möglich.

Langsamer klar, aber sooooo langsam Zumal das nicht nur ein Benchmark ist. In diesem Forum gibt es mehrere unabhänigige Berichte, dass dies so auch in der Praxis auftritt.

Wenn hier ein paar Benchmarker mit zuviel Zeit dabei sein: Mal ein degraded Linux mdadm RAID5 bei gleicher Hardware dagegen laufen lassen. Sollte deutlich höhere Performance bringen, womit dann belegt wäre, dass das doch ein sehr ärgerliches Implementierungs"feature" von Intel ist.

Trotzdem ist RAID5 bei SoftRAIDs nicht toll, wegen WriteHole.

 

[H_M_Murdock]

Ich glaub was beim RAID 5 eine noch viel größere Rolle spielt als das XOR (das machen aktuelle CPUs wirklich mit links) ist das Caching.
Wenn ich auf dem 3Ware Controller in meinem Server den Controller-Schreibcache deaktiviere bricht die Schreibperformance auch ins bodenlose ein.

 

[borgfish]

richtige raidcontroller arbeiten gerne ohne schreibcache der platten, wenn man dann den eigenen controllercache deaktiviert gibts garkeinen cache mehr.....
kein plan aber denkbar wäre dass die "soft-controller" auch den cache der platte deaktivieren ? glaub ich aber nicht, das ist denen bestimmt egal...

 

[7oby]

Ich glaub was beim RAID 5 eine noch viel größere Rolle spielt als das XOR (das machen aktuelle CPUs wirklich mit links) ist das Caching.

Das Caching ist davon unabhänig.

Das kannst Du auch bei den SoftRAIDs aktivieren u. deaktivieren. Bei Intel heißt das dann Rückschreibcache auf Deutsch:

Volume-Rückschreibcache aktivieren/deaktivieren: Eine Aktivierung des Volume-Rückschreibcache bewirkt einen verbesserten I/O-Durchsatz und erhöhte Schnelligkeit, kann jedoch den Datenschutz im Falle eines Strom- oder Systemausfalls beeinträchtigen. Zur Änderung dieser Option ist kein Neustart erforderlich.

HINWEIS: Aus Datenschutzgründen wird der Rückschreibcache vorübergehend deaktiviert, wenn UPS (Uninterruptible Power Supply) eingesetzt wird.

Natürlich hat der Schreibcache Auswirkungen auf die Schreibleistung, solange ich "nur" in den Cache schreibe. Bei einem PC-System mit 4GB u. mehr Arbeitsspeicher ist der Effekt auch gravierend. Das macht das benchen solcher Systeme mit gewissen tools nicht immer einfach.

Die Dauertransferrate sobald ich deutlich mehr Daten schreibe als ich Hauptspeicher habe, ist davon aber unabhängig. Zumindest sollte sie es sein - alles andere wäre eben ein Bug.

 

[H_M_Murdock]

Bei den 3Ware Controllern lässt sich der Controller-Cache getrennt vom Plattencache steuern (über die StorSave Profile).
Bei "Performance" ist der Plattencache an, bei den beiden drunteren Einstellungen aus.
Und der Controllercache ist ohnehin getrennt davon ein- und auszuschalten.

Und mit dem StorSave Profil "Performance" und ohne Controller-Schreibcaching ist die Schreibperformance eine einzige Katastrophe.

Ist im Prinzip auch ganz logisch:
Der Controller bekommt Daten, die muss er jetzt erstmal aufteilen (Striping) und dann aus den Stripes die Prüfsumme errechnen (XOR).
Erst wenn die Stripes und die Prüfsumme errechnet sind können die in Richtung Platte gehen, d.h. bis dahin ist der Plattencache auch vollkommen uninteressant.
Wenn nun der Controller die eingehenden Daten vor der Verarbeitung nicht vernünftig cached, kann es durchaus zu solchen Performance-Einbrüchen kommen.

 

[Schlingel_INV]

stimmt so nedd auch mit "vollem" cache hast immer noch enorme vorteile gegenüber keinem cache bzw write through.

schönes bsp:

http://www.hardwareluxx.de/community/showpost.php?p=12403596&postcount=1869

und jopp bei den meisten hw-raids kannst beide caches steuern (controller als auch platte).

bei nem softraid kannst zwar auch in den write back wechseln, jedoch hast

A: dann den umweg über den ram und
B: keinerlei sicherung im fall eines zufälligen BSOD oder stomausfalls. 4GB daten wech wäre nicht so dolle. dann ist das filesystem komplett hinne.

 

[7oby]

An einem ziemlich alten ICH8 bringt ein Linux Soft RAID5 im sequenziellen Schreib-Durchsatz bis zu 450 MB/s:
http://home.comcast.net/~jpiszcz/20...ks-3to10-veliciraptors/veliciraptor-raid.html
http://kerneltrap.org/mailarchive/linux-kernel/2008/6/7/2058914

Warum diese dämlichen Host-RAID Controller diese Performance NICHT bringen - ist mir schleierhaft. Dafür gibt es keinen echten Grund - sie tun es nur schlicht nicht.

Das ist alles völlig unabhängig von Schreibcaches, die man an und abschalten kann. Und zwar sowohl von den Festplatten-, Controller- und OS-Schreibcaches. Dass Write-Back Caches sich günstig auf die Performance auswirken ist eine Binsenweisheit.