RAID10 an ICH9 - Performanceprobleme

[Ernst@at]

Beim lesen ist ein Raid 5 aus 4 Platten also nichts anderes als ein Raid 0 aus 4 Platten.

Soll wohl heissen: ... ein RAID 0 aus 3 Platten - schreibst ja selbst, dass er beim Lesen die Parityinfo (auf der 4.Platte) nicht benutzt

Wie hast Du aus 4 x 320er Platten ein Raid 5 mit 960 GB erstellen können?

Ist (4-1)*320 nicht 960? Alles andere wäre Zauberei

 

[Humptidumpti]

Soll wohl heissen: ... ein RAID 0 aus 3 Platten

Nö. Ist ja nicht so das die Paritydateien immer auf einer speziellen Platte liegen und diese beim lesen komplett ausgelassen wird.

 

[cemetery]

Doch macht Sinn. Beim Lesen von einem Raid 5 werden keine Paritydateien berechnet. Das ist nur beim schreiben notwendig. Beim lesen ist ein Raid 5 aus 4 Platten also nichts anderes als ein Raid 0 aus 4 Platten. Dein Raid 5 wird allerdings nichtmal die Schreibperformance einer Singleplatte erreichen.

Das macht Sinn. Dass die Schreibperformance erst mit seperatem Controller und aktivierten Write Back Cache erst richtig gut wird ist auch klar.

Hier auch ein Benchmark das deine Aussage auch untermauert.

Ich bin immernoch der festen Überzeugung das ein Raid 10 oder 0+1 auf einem Onboard Controller deutlich schneller vorallem in Schreiboperationen ist als ein Raid bei dem Parityberechnungen notwendig sind.

Der Fehler bei dir lag entweder in einem Setting des Arrays oder einem Fehler des Ausleseprogrammes.

Naja, so wirklich viel kann man bei dem ICH9 eigentlich gar nicht konfigurieren, folglich auch eigentlich nicht viel falsch machen.


Abschliessend kann ich sagen das ich nochmal alles überdacht habe und zu dem Schluss gekommen bin mir als Systemplatte eine SSD zu gönnen. Als reines Datenarray reicht das Software Raid 5 dann erstmal vollkommen aus. Wenn meine Ansprüche irgendwann steigen kann ich später immer noch einen Hardware Raidcontroller mit XOR CPU nachrüsten.

 

[werkam]

@Ernst@at

Ist (4-1)*320 nicht 960? Alles andere wäre Zauberei

Stimmt, hatte einen kleinen Denkfehler.

 

[Humptidumpti]

Hier auch ein Benchmark das deine Aussage auch untermauert.

Sogar ohne Write Back Cache. Da der Controller momentan ohne BBU ist steht er auf Write through.

 

[cemetery]

@Humptidumpti

Sieht natürlich deutlich besser aus. Aber mit BBU und aktivierem Write Back würde das noch ein gutes Stück besser aussehen. Also der Abstand zwischen Read und Write sollte dann nur noch minimal sein.

Vielleicht ergibt sich ja mal ein Adaptec 3405 oder 5405 dann passt die Gesamtperformance wieder. (Perc ist mir zu doof mit dem Intelchipsatz)

Aber langsam driften wir ab

 

[Ernst@at]

Nö. Ist ja nicht so das die Paritydateien immer auf einer speziellen Platte liegen und diese beim lesen komplett ausgelassen wird.

Das ändert aber nichts an der Tatsache, dass bei einem RAID5 mit 4 Platten jedes Stripeset aus drei Datenstripes und einem Paritystripe besteht.
Nachdem beim sequentiellen Lesen der Sektoren die Übertragungsrate ja von der Geschwindigkeit abhängt, mit der jeder Kopf die Daten von der Oberfläche lesen kann, wäre die Datenrate bei 4 Platten zwar 4x so hoch, es sind aber nur 3 von 4 Sektoren Datenstripes, und wenn auch das Paritystripe nicht gelesen wird, muss ja trotzdem gewartet werden, bis es unter dem Lesekopf vorbeigezogen ist, bevor das nächste Datenstripe von diesem Kopf gelesen werden kann.

Sie Dir doch Dein eigenes Bildchen an: Unter der Annahme, dass das Lesen eines Stripes von der Oberfläche 1 Zeiteinheit benötigt, können von einer Einzelplatte 4 hintereinanderliegende Stripes in 4 Zeiteinheiten gelesen werden.
Bei Raid5 dauert das Lesen von A1-D3 von 4 Platten gleichzeitig ebenfalls 4 Zeiteinheiten (wenn man die Asynchronität der Positionen des Spurbeginns mal weglässt), und in diesen kannst Du nur 12 Datenstripes lesen - also 3x soviel.