Re: geom_*, atacontrol oder Hardware?

On Tue, Nov 16, 2004 at 09:09:42AM +0100, Daniel Graupner wrote:
> Hallo,
>
> also ich steh jetzt davon auf ner FBSD 5.3 Kiste ein Raid1 (Mirror) zu
> verwirklichen. Das ganze kann ja auf verschiedene Weise passieren,
> allerdings brauche ich mal einen kleinen Denkanstoß...
>
> 1. geom_mirror
> Habe ich probiert, das gmirror utility ist recht intuitiv. Ich habe
> einfach mal ein paar Optionen ausprobiert und als ich dann /dev/mirror/*
> unmountet habe und den Mirror entfernen wollte -> Kernel Trap und
> Komplettabsturz ... irgendwie nicht sehr vertrauenserweckend.
> Ausserdem, Nachdem der Mirror beim booten erkannt wurde kam eine Meldung
> der Art:
> Interrupt Storm at <snip> detected <snip> throtteling <snip>
> Und der Mirror hing irgendwie immer im SYNCHRONIZING State...

Kann ich nicht viel zu sagen - mir sind die Dinger allerdings sehr
suspekt - und das hat jetzt nichts mit deinen Meldungen zu tun.

> 2. der adaptec-sata controller bietet ja von sich aus ein Raid1 an. Wenn
> dieser Controller direkt von Freebsd unterstützt wird, kann ich das ja
> auch nutzen. Aber wie kriege ich dann den Status der Platten mit?
> Sprich, wenn eine kaputtgeht?

Keine Ahnung wie das mit deinem Controller ist, aber sehr viele melden
das vom Kernel aus.
Ich denke mal das wird auch mit dem der Fall sein - im Zweifelsfall mal
ausprobieren.

> 3. atacontrol, legt bei mir ein /dev/ar0 an, ich nehme mal an atacontrol
> realisiert auch software-raid, oder?

Ja - und das defintiv nicht mal Statefull.

> Mit gvinum hab ich noch nicht angefangen...weiß nicht inwiefern das
> Stable ist.

Ich kann dir nicht sagen inwieweit geom und dein Adaptec statefull
sind, aber vinum ist es.
Meine Erfahrungen mit gvinum sind enttäuschend gewesen und ich benutze
noch das klassische.
Das mag sich inzwischen geändert haben, aber vertrauen kann ich dazu
noch nicht wirklich haben.

Im RAID Bereich ist es sehr entscheided zu wissen in wie weit die
Platten noch syncron sind.

Grundsätzlich muss ein Plattenausfall verzeichnet werden, weil die
Platte ja nach dem Ausfall nicht mehr auf Stand gehalten wird.
Wenn die Platte später wieder läuft darf das System die nicht als
syncron annehmen.
Zumindest Vinum und Raidframe kümmern sich darum.

Weiterhin sind bei Schreib Transaktionen immer mehrere Platten
beteiligt und die Platten schreiben niemals physikalisch gleichzeitig.
Wenn du nun einen Stromausfall hast kann es passieren, dass eine
Platte geschrieben hat und die andere nicht.
Jetzt kannst du beim booten die vollständige Syncronität prüfen was
recht lange dauert oder zu weißt an welchen Stellen noch Transaktionen
ausstanden und prüfst nur noch diese Stellen.
Letzteres geht nur indem man sich die Transaktionen auf einem nicht
flüchtigen Medium speichert.
Das Spielchen geht nur mit NVRAM oder durch einen riesigen Performance-
overhead auf den Platten selber.
Außerdem dürfen die Festplatten das RAID System nicht darüber belügen
ob die Daten noch im Schreib Cache sind oder schon auf dem Speicher-
medium - das belügen ist ein typisches Problem mit IDE Platten.
Vinum kümmert sich leider nicht darum und heutzutage haben auch sehr
viele RAID Controller kein NVRAM woraus man aufgrund der Performance
annehmen kann, dass auch diese das Problem nicht behandeln.
Raidframe kümmert sich auch darum, aber Raidframe ist unter FreeBSD
leider unbrauchbar und da es kein Zugriff auf NVRAM hat auch in
der Geschwindigkeit entsprechend benachteiligt.
Unwissenheit über RAID Asyncronität kann ganz gravierende Probleme
nach sich ziehen und im Fall von RAID5 sogar Dateninhalte beeinflussen
an deren Inhalt schon lange vor auftreten der Asyncronität geschrieben
wurden.
Es ist deshalb zumindest erforderlich die Syncronität von Zeit zu Zeit
mal überprüfen zu können.

-- 
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