Raid 5 ungerade Anzahl Platten

Warum sollte das so sein, dass ist genau die Frage.

Die grundsätzliche Funktionsweise ist mir schon klar. Allerdings hält sich ja hart das Gerücht, dass die Zahl ungerade sein sollte. Nur finde ich keine stichhaltige Erklärung dafür.

z.B. hier:

IONOS Raid 5 Erklärung

Zitat:

"Typischerweise wählt man im Übrigen eine ungerade Zahl an Datenträgern, also drei, fünf, sieben usw."

Na das klingt so technisch, das muss die Lösung sein Zumindest erschließt sich mir die Begründung.

Dann halten wir fest, dass es schon irgendwie seinen Sinn hat(te) aber vermutlich mit der heutigen Technik keine messbaren Auswirkungen mehr. Ansonsten hätten die Hersteller an irgend einer Stelle schon irgendwie drauf hingewiesen.

Danke an Alle für den Input

Auf Wikipedia hätte man auch mal alleine kommen können. Hier steht schön beschrieben, warum Raid 5 mit einer geraden Anzahl von Platten suboptimal ist und es hat (so wie es klingt) auch heute noch Relevanz.

Zitat Wikipedia:

Im Unterschied zur Read-Performance ist das Ermitteln der Write-Performance bei RAID 5 deutlich komplizierter und hängt sowohl von der zu schreibenden Datenmenge, als auch von der Anzahl der Platten ab.[4] Ausgehend von Festplatten mit weniger als 2 TB Plattenplatz, ist die atomare Blockgröße (auch Sektorgröße genannt) der Platten häufig 512 Byte (siehe Festplattenlaufwerk). Geht man weiter von einem RAID-5-Verbund mit 5 Platten (4/5 Daten und 1/5 Parität) aus, so ergibt sich folgendes Szenario: Will eine Anwendung 2.048 Byte schreiben, wird in diesem günstigen Fall auf alle 5 Platten genau je ein Block zu 512 Byte geschrieben, wobei einer dieser Blöcke keine Nutzdaten enthält. Im Vergleich zu RAID 0 mit 5 Platten ergibt sich daraus eine Effizienz von 80 % (bei RAID 5 mit 3 Platten wären es 66 %). Möchte eine Anwendung nur einen Block von 512 Byte schreiben, so ergibt sich ein ungünstigerer Fall, es müssen zuerst der abzuändernde Block und der Paritätsblock eingelesen werden, danach wird der neue Paritätsblock berechnet und erst dann können beide 512-Byte-Blöcke geschrieben werden. Das bedeutet einen Aufwand von 2 Lesezugriffen und 2 Schreibzugriffen, um einen Block zu speichern. Geht man vereinfacht davon aus, dass Lesen und Schreiben gleich lange dauern, so beträgt die Effizienz in diesem ungünstigsten Fall, dem sogenannten RAID 5 write Penalty, noch 25 %. In der Praxis wird dieser Worst-Case-Fall bei einem RAID 5 mit 5 Platten aber kaum eintreten, denn Dateisysteme haben häufig Blockgrößen von 2 kB, 4 kB und mehr und zeigen daher praktisch ausschließlich das Well-Case-Schreibverhalten. Gleiches gilt analog für RAID 5 mit 3 Platten. Unterschiedlich verhält sich hingegen etwa ein RAID-5-System mit 4 Platten (3/4 Daten und 1/4 Parität), soll hier ein Block von 2.048 Byte geschrieben werden, sind zwei Schreibvorgänge notwendig, es werden dann einmal 1.536 Byte mit Well-Case-Performance geschrieben und noch einmal 512 Byte mit Worst-Case-Verhalten. Diesem Worst-Case-Verhalten wirken zwar Cache-Strategien entgegen, aber dennoch ergibt sich hieraus, dass bei RAID 5 möglichst ein Verhältnis von zwei, vier oder auch acht Platten für Nutzdaten plus einer Platte für Paritätsdaten eingehalten werden sollte. Daher haben RAID-5-Systeme mit 3, 5 oder 9 Platten ein besonders günstiges Performanceverhalten.

Hab in einem anderen Forenbeitrag folgendes gefunden, was in dem Kontext Sinn macht.

Mehr Platten = mehr Leistung (Da die Last auf mehr Platten verteilt wird, wenn der Controller es schafft)
Gerade Anzahl Platten = weniger Leistung

Damit soll sich grob folgende Faustformel zur Geschwindigkeit ergeben:

3=4
4<5
5=6
... usw


Naja, so funktioniert das glaub nicht. Die Blockgröße bei drehenden Platten ist 512 Byte. SSDs arbeiten meistens mit 4KB Blöcken, emulieren aber auf Wunsch die 512 Byte um die Kompatibilität zu gewährleisten. Jedenfalls gibt das Dateisystem vor, in welcher Blockgröße es gern die Daten hätte.

Es geht nicht um den letzten Block, welcher vermutlich immer aufgesplittet werden muss, sondern um die ganzen Blöcke davor wenn man zB mal 10MB schreiben muss, da auch die 4k Blöcke nicht sauber durch 3/5/7... (Datenplatten) geteilt werden können und damit jedes mal diesen doppelten Schreibaufwand produzieren.

Ob der Cache den Effekt jetzt abfängt, hängt glaub von der Intelligenz der Raidcontroller ab. Dazu hab ich aber nun gar nichts mehr gefunden.