Re: raid5 mit geom_vinum vs graid3

On Tue, Jun 07, 2005 at 12:48:30PM +0200, Michael Gusek wrote:
> Hallo !
>
> Ich steh gerade vor der Aufgabe mein laufendes Raid5 unter gvinum
> anfassen zu müssen. Ein anderer Thread in dieser Liste hat mich etwas
> nachdenklich gemacht, ob gvinum das Richtige für mich ist. Für würde
> gerne ein paar Meinungen von euch über die Vor- und Nachteile von graid3
> und gvinum hören. Im Moment laufen bei mir 4 Platten im Raid5. Laut
> Manual kann graid3 aber nur 3, 5, 9 ... Platten verwalten. Angeblich ist
> Raid5 im schreiben schneller, während Raid3 im lesen schneller ist. Nun,
> meistens wird ja eh gelesen. Mich interessiert besonders, wie graid3 im
> Fehlerfall reagiert und wie die Handhabe ist. Bei gvinum hab ich schon
> einige Erfahrungen gesammelt. Was mir nicht an gvinum gefällt, ist, dass
> ich es unter Current betreiben muss, da einige Funktionalität
> (checkparity, rebuildparity) in 5.3 gefehlt haben, hat sich da was
> geändert ?

Die Unterschiede zwischen Raid3 bis 4 sind nur in der Organisation der
Daten und Parität.
Die Technik der Redundanz als solches ist identisch, lediglich die
Performance unterscheided sich.
Da mit dem schnellen lesen ist aber bei modernen Platten eine sehr
theoretische Sache, da diese große preread caches haben, welche
beim lesen eines Blocks ohne zusätzliche Zeit gleich mit gefüllt
werden - du brauchst da schon eine sehr spezielle Anwendung um da
noch einen Gwinn draus zu erzielen.
Im Normalfall ist RAID3 langsammer, da man nicht mehr auf die
mittlere Transaktionszeit einer Platte wartet, sondern auf die
jeweils größte beider Daten-Platten.
Außerdem bricht es die vom FS mühselig groß gemachten Transaktionen
wieder in viele kleine auf.
Ich habe keine Ahnung, warum das implementiert wurde - vermutlich
hatte jemand so eine spezielle Anwendung oder es war Spieltrieb.
R5 ist für den Normalfall eigendlich deutlich besser geeignet - erst
recht beim reinen lesen.

Der Bedarf nach 2^n+1 Platten bei R3 ist übrigens nur aus praktischen
Gründen existent, da sich die logische Blockgröße erhöht.
Eine Einzelnplatte macht normalerweise 512 Byte Blöcke und mit
2 Datenplatten hat man logische 1024, mit 3 Datenplatten hat man
1526, mit 4 2048 - dazu kommt dann noch die Paritätsplatte.
Nun können die meisten FS nur mit 2^n was anfangen.
Auch mmap Zugriffe sind 2^n orientiert, da eine Page im Regelfall
4 oder 8k groß ist.

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