Re: Raid 3 vs. 5

On Thu, Apr 05, 2007 at 06:58:19PM +0200, Oliver Fromme wrote:
> Bernd Walter wrote:
> > Oliver Fromme wrote:
> > > Oliver Fromme wrote:
> > Wie oft muss ich den Unsinn hier noch lesen?
> > Die Paritätsplatte wird bei R3 nicht stärker belastet als die
> > anderen, sondern beim schreiben gleich stark und beim lesen gar
> > nicht.
>
> Ich habe mir jetzt mal die Mühe gemacht, in den Source zu
> gucken. :-) graid3 arbeitet tatsächlich byteweise,
> nicht blockweise, und ist daher wirklich eine RAID-3-
> Implementation. Das hat zur Folge, dass bei einem
> Schreibzugriff auf _alle_ Festplatten geschrieben werden
> muss (bei RAID-5 nur auf zwei), insofern werden sie
> tatsächlich alle gleich stark belastet. (Beim Lesen wird
> die Parity-Platte nur verwendet, wenn man die Option -r
> von graid3 angibt.)

Ja - bei R5 werden nur auf zwei Platten Daten geschrieben,
aber wegen der differentiellen Parität zudem vorher von den
gleichen Blöcken die Daten gelesen, damit die Differenz gebilded
werden kann.
Da die Tranaktionen nacheinander laufen ist das schlecht für die
Latenz und da das sogar die gleichen Datenbloke sind kann es
sogar bei nichtlinearen Zugriffen zu Strafumdrehungen führen.
Lineare Zugriffe sind bei heutigen Festplatten zum Glück zumeist
im Cache, sodass der zusätzliche Lesezugriff keine große Konsequenz
hat.
Im Schreiben kann R3 gegenüber R5 deshalb sogar dann schneller sein,
wenn es sich um nicht-lineare Zugriffe handelt.

> Bei RAID-4 (wofür FreeBSD nun leider keine Implementation
> hat) werden dagegen die Datenplatten beim Schreiben im
> Schnitt jeweils nur halb so stark belastet wie die Parity-
> Platte, wenn man drei Platten hat (bei Random Access).

Ja, aber mit den gleichen Nachteilen, wie bei R5.

> > Wie komst du auf die Idee, dass graid3 eher eine R4 Implementiertung
> > ist?
>
> Die Option -r in der Manpage hat mich irritiert. Das
> Feature, dass die Parity-Daten zum Lesen genutzt werden
> können, kannte ich bisher nur von RAID-4 (und RAID-5
> natürlich). Auf welche Weise RAID-3 dadurch 40% schneller
> werden kann, wie die Manpage behauptet, ist mir unklar.

Beim lesen ist die Paritätsplatte unbenutzt und da im Gegensatz
zu R4 und R5 das degraded lesen lediglich um den xor langsammer
ist, als bei einem normalen Zugriff, kann man zwischenzeitlich die
Paritätsplatte mit einbeziehen.
Das theoretische Maximum bei einer 3-Platten Konfiguration wäre 50%.
Allerdings kann das bei linearen Zugriffen kaum greifen, da die
Platten die Daten zumeist im Cache gehabt hätten.
Das ist von den Risiken und Nutzen her ziemlich ähnlich zu R1, wo man
entweder immer von dergleichen Platte liest, oder beide zum lesen
benutzt.
Solange die Syncron sind ist das Ok, wenn die mal nicht syncron sind
kann ein und derselbe Zugriff zu unterschiedlicher Zeit unter-
schiedliche Daten liefern, also z.B. ein fsck sauber durchlaufen und
das FS macht hinterher doch einen Panic.

> In der Praxis will man sowohl RAID-3 als auch RAID-4 wohl
> eher nur selten haben, außer für ganz wenige, spezielle
> Anwendungsfälle. Bei HDR zum Beispiel könnte RAID-3
> vorteilhaft sein.
>
> Inden meisten Fällen, wo Redundanz gefordert wird, will
> man entweder RAID-1 oder RAID-5 (oder RAID-6, aber das
> bietet FreeBSD ebenfalls nicht an).

Gerade wo Redundanz gefordert ist macht R3 durchaus Sinn.
Wie ich schon in einer anderen Mail geschrieben habe gibt es ein
deutlich geringeres Risiko einer Paritätsinkonsitenz im Vergleich zu
R4 und R5.
Stelle dir vor das FS schreibt einen 1k Block.
Jetzt hast du einen Stromausfall und die Parität ist alt, während die
Daten neu sind.
Die Parität ist also nicht mehr syncron.
Normalerweise sollte die beim Neustart syncronisiert werden, aber die
Erfahrung zeigt, dass genau hier viele Controller schludern, da es
langsamm ist den gesammten Datenbestand zu prüfen und NVRAM zum merken
fehlt - selbst mit NVRAM kommt es oft vor, dass dieses nicht hierfür
genutzt wird.
Das kann soweit auch mit R3 passieren - der Unterschied ist die Folge
dadurch.
Bei R3 ist der falsch beschriebene Datenblock bei einem Plattenausfall
nicht mehr richtig.
Bei R4 und R5 sind vollkommen unbeteiligte Datenblöcke in Mit-
leidenschaft gezogen, da die zufällig die Parität mit dem beim Ausfall
geschriebenen teilen.
Somit können bei einem R4 und R5 auch Daten kaput gehen, die schon
lange nicht mehr verändert wurden.
Zudem hält sich eine Asyncronität der Parität durch die differentielle
Technik, während bei R3 die Parität bei einem Schreibzugriff immer
neu geschrieben wird.
Man sollte zwar nicht nur bei R5 die Syncronität regelmässig prüfen,
aber hier ist das besonders sensibel - umso tragischer finde ich,
dass einige Implementierungen diese wichtige Funktion nicht bieten.
Das vermisse ich z.B. auch bei den GEOM Varianten gegenüber Vinum.

Ein weiteres Argument für R3 ist, dass die Geschwindigkeit im degraded
Fall nur unwesentlich einbricht, während bei R5 ein sehr starker
Einbruch vorhanden ist.
Wenn man einen Server mit RAID betreiben will, dann muss das Platten-
system auch dann noch schnell genug sein, wenn eine Platte ausfällt
und bei R5 ist der Einbruch sehr groß.
Es geht schliesslich um Verfügbarkeit der Daten und dazu gehört auch
die für die Anwendung erforderliche Geschwindigkeit.
R3 ist in der Praxis keineswegs eine reine Sache für HDR.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd(at)bwct.de           info(at)bwct.de            support(at)fizon.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message