gvinum raid5 - rebuild nach Austausch defekter Platte

H

heimdall

New Member
Hi,

ich habe ein raid5 mit gvinum und benutze folgende Konfiguration:

3x Seagate 250GB SATA
2 davon an Motherboard VIA SATA
1 davon an Promise SATA Controller

Das raid lief anfangs ohne Probleme, war auch im Gegensatz einiger Berichte anderer Benutzer sehr schnell (write: 25 M/s, read: 70M/s, Athlon XP2500+), bis eine Platte einige Sektoren nicht mehr lesen konnte und damit stale wurde. Nachdem ich sie ausgetauscht habe (1:1 gleiches Modell), weiß ich nicht, wie ich das raid neu initialisieren soll. Ich habe bereits slice und partition auf ihr angelegt wie auf den anderen beiden (wie es auch zu Anfang war). Dabei bin ich nach

http://wiki.bsdforen.de/index.php/FreeBSD_-_gvinum_raid5

vorgegangen.
Aber prinzipiell muss ich doch noch irgendwie dem gvinum sagen, welche Platte er nun als Ersatzplatte nehmen soll, denn ich könnte ja 1e4 Platten verbaut haben :-) und da kann er sich ja nicht einfach eine greifen.

Also: wie sage ich gvinum, welche Platte er wieder für das fehlende raid drive einbinden soll?
Muss ich da nochmal gvinum create ausführen? Ich fürchte, dass er dann alles zerstört...

Hier noch Infos:
---------------------------------------------------------
seth# gvinum list
2 drives:
D seag0 State: up /dev/ad8s1a A: 0/238474 MB (0%)
D seag1 State: up /dev/ad6s1a A: 0/238474 MB (0%)

1 volume:
V data State: down Plexes: 1 Size: 232 GB

1 plex:
P data.p0 R5 State: down Subdisks: 2 Size: 232 GB

3 subdisks:
S data.p0.s2 State: stale D: seag2 Size: 232 GB
S data.p0.s1 State: up D: seag1 Size: 232 GB
S data.p0.s0 State: stale D: seag0 Size: 232 GB
---------------------------------------------------------
Ich benutze:
FreeBSD 6.0-STABLE #2: Wed Jan 4 23:01:45 CET 2006


Vielen Dank,
Christoph
 
Hi, eigentlich brauchst du nur deiner neue Festplatte einen Namen geben, sodass nur:
drive eins device /dev/ad1s1a
in der config steht.
und dann mit gvinum create namederconfigdatei benennen.
Danach sollte gvinum das raid5 wieder ans rennen bringen.
Notfalls noch ein gvinum start namedeinesraids machen.
 
Was meinst du genau mit Namen geben?
Die alte config nehmen, die neue Partition im neuen Slice auf der neuen Platte eintragen (statt der alten defekten)?
Dann create und vielleicht noch start?
 
Ich weiß nicht ob man das mit der alten config so machen kann. Mir war so, als ob ich ne Fehlermeldung von gvinum gesehen hatte, als ich versucht hatte ner Festplatte den selben Namen zu geben, was bei den heilen Platten ja der Fall wäre. Dafür ist doch so eine Zeile in der config zuständig oder? drive eins device /dev/ad1s1a. Mmh. Naja irgendwie so ähnlich. Müssen das nochmal irgendwie ins Wiki schreiben, wie das nun genau geht und auch wie man sone config wieder von den Festplatten bekommt. Da gibt es ja nicht soviel Doku drüber. Wie denkst du darüber Maledictus?
 
Ich habe folgendes getan:
Eine Platte komplett mit /dev/zero "abgeglichen" :-) , dann neu gebootet:
Das Array war degraded, die Daten waren noch da, das Drive natuerlich nicht.
echo "drive drei device /dev/ad2s1a" >rescue.conf
gvinum create rescue.conf
Gvinum hat die Platte gefunden und hat das Array wieder UP genommen, da kam auch schon ein kernel trap 12 (oder so aehnlich). Nach einem Neustart war die Platte wieder weg!
Mit anderen Worten: Ich hab's probiert, aber nicht geschafft - Hat jemand noch Ideen, die ich hier mit meinem Testsetup ausprobieren kann?
 
Vielen Dank für deine Antwort free!
Bei meinen Tests mit QEMU gab es beim gvinum create sofort den Panic.

Ideen hab ich leider auch nicht, außer mal ne eMail an Lukas Ertl zu schreiben :)
 
Dem hab' ich schon vor einer Woche geschrieben, er hat leider noch nicht geantwortet. Aber er hat mir neulich schon gesagt, dass er momentan wenig Zeit hat...
 
Also ich finde das schlimm (schon fast peinlich), dass die Doku zu gvinum so unvollständig ist. Zudem hab ich das Dateisystem mit Hilfe von gvinum ebenfalls innerhalb von Sekunden so kaputt gemacht, dass nur noch ein panic() geschmissen werden konnte. Ich wollte zu diesem Beitrag nur helfen, aber das war nicht möglich.

Würde jemand von den Leuten, die gvinum wirklich brauchen, mal an die entsprechenden Mailing-Listen etwas dazu schreiben? Ich vermisse die Zeiten, in denen noch alle Fragen im Handbuch geklärt wurden. Langsam wird das zum Missstand hier.
 
Ja dann schreib doch mal auf, wie du mit gvinum diesen Fehler erzeugt hast.
Speicher deine Konfiguration in eine datei dmesg>test.
und ein sysctl -b kern.geom.confxml >test2.
gvinum list >test3
Diese Sachen kann man den jeweiligen Committern schicken und die freun sich immer, wenn man mit denen zusammen Fehler findet und ausmerzt.
Folgende Befehle gehn mit gvinum
add - erzeugen von Subdisks, Plex und Volume
rm - Löschen von Subdisks, Plex und Volume(Plex und Volume lassen sich nur nach Neustart löschen)
create - erzeugen des Raids
help - anzeige aller Befehle
start - Raid5 initialisieren

Das hab ich jetzt mal so selbst rausgefunden und hier veröffentlicht.
gvinum Raid5 + geli geht definitiv noch nicht. Es wird sich darum aber gekümmert.
Striped + geli geht aber sehr gut.
Das aber auch nur durch meine Eigeninitiative. Man muss halt mal den Mut aufbringen und den Comittern ne nette Mail mit genauer Fehlerbeschreibung senden.
Man muss sich jetzt nur noch die Arbeit machen es ins wiki zu schreiben.
Man darf auch nicht vergessen, dass wir das hier alles freiwillig tun.
Also wenn jemand etwas Zeit aufbringen kann, dann soll man das mit der Doku halt selber in die Hand nehmen und sich im FreeBSD Handbuch verewigen.
 
Langsam habe ich echt das Gefühl, man sollte gvinum einfach in die Tonne treten, nen Spendenaufruf machen und irgendwen mit skill (pjd?) bezahlen um graid5 zu schreiben. Die ganze Denkwelt und Kompliziertheit von gvinum passt imo überhaupt nicht zu geom.
 
Hi,

also, ich hab mir das mal durchgelesen und da ist mir aufgefallen, dass ich ja mal ein ähnliches Problem unter FBSD5.4 hatte. Muss eigentlich auch noch hier im Forum stehen.

Als erstes solltest du die SATA-Kabel prüfen. Das war bei mir damals der Grund, warum nichts mehr ging. Und ich hatte auch zuerst die HDD im Verdacht, hab dann aber in einer entsprechenden NG nachgefragt und eben den Hinweis auf die Kabel bekommen.

Ansonsten brauchst du die neue HDD nur anstelle der alten einbauen, normal labeln, newfs laufen lassen, dann für dein Gvinum labeln. (keine Ahnung, ob man das newfs zwischendrin auslassen kann ... ich hatte ohne öfter mal probleme, daher ab jetzt immer mit).

Das label sollte so aussehen, dass die HDD genau die defekte ersetzt. Sprich, du musst darauf achten, dass die Eintragungen genau übereinstimmen. Kannst du ja einfach mittels bsdlabel bei einer der anderen HDDs auslesen.

Das ergebnis sollte sein, dass du wieder 3 HDDs hast, deren Einträge in /dev der alten Config entsprechen. (also solltest du auch vorsichtig mit dem Tauschen des Anschlusses beim Controller sein) Dementsprechend kannst du deine alte gvinum.conf weiterverwenden.

Erst jetzt startest du das Gvinum.

Dann mach mal ein List und du wirst sehen, dass das Raid down ist. Dann gib einfach start ein und die Kiste sollte mit dem Rebuild beginnen. ein checkparity oder ein rebuildparity habe ich nie benötigt.

Versuch es einfach mal und poste die Ergebnisse.

Wie gesagt, bei mir hat's am Kabel gelegen, die HDD wurde aber dennoch komplett neu initialisiert und natürlich waren auch die Daten auf dem Raid noch da :-)

Also, nicht aufgeben!

Gruß

Hazel
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben