VINUM <-- Erfahrungsbericht

marzl

Well-Known Member
VINUM <-- Erfahrungs-/Leidensbericht

Hallo Leutz,

ich hab n Hals. :(
Ich hatte doch mal erwähnt das ich Vinum für mein Raid5 benutze.
Soweit so gut, hat ja auch alles prima funktioniert, ABER:
Jetzt ist es tatsächlich passiert: Eine Platte hat den Geist aufgegeben. Peng.
Also Rechner runter, Festplatte raus, Rechner hoch.
Nach meinem Verständnis über Raid5 sollte jetzt alles normal weiterfunktionieren, .... dem ist aber nocht so.
Die grossteil der Daten ist inkonsistent, wenn nicht sogar weg oder in lost+found. toll. obertoll.
also das kann es nicht sein.
vinum hat bei mir erstmal verschissen und fliegt bei nächster Gelegeheit vom System.
 
Zuletzt bearbeitet:
Original geschrieben von marzl
Hallo Leutz,

Nach meinem Verständnis über Raid5 sollte jetzt alles normal weiterfunktionieren, .... dem ist aber nocht so.
Die grossteil der Daten ist inkonsistent, wenn nicht sogar weg oder in lost+found. toll. obertoll.
also das kann es nicht sein.
vinum hat bei mir erstmal verschissen und fliegt bei nächster Gelegeheit vom System.

Hi marzl.

Na ja, Raid-5 arbeitet so, dass er die ECC-Daten zusammen mit den Nutzdaten über alle Platten gleichmäßig verteilt. Dadurch verzichtet Raid-5 auf ein dediziertes Parity-Laufwerk.

Raid-5 ist vor allem wegen seiner Schnelligkeit im Einsatz (z.B. bei Datenbanken) ... was die Reparaturfähigkeit (also eine Platte fällt z.B. aus) angeht, so ist er wohl nich so gut wie z.B. Raid-6 bei dem auch eine Parity-Platte im Einsatz ist. Dieser ist aber dafür nicht so schnell wir Raid-5. Das ist aber immer so, bei allen Raids, eines haben die im Vorteil anders dafür im Nachteil.

Gruß und alles Gute mit neuen Platten

CW
 
Original geschrieben von marzl
Also Rechner runter, Festplatte raus, Rechner hoch.
Nach meinem Verständnis über Raid5 sollte jetzt alles normal weiterfunktionieren, .... dem ist aber nocht so.
Die grossteil der Daten ist inkonsistent, wenn nicht sogar weg oder in lost+found. toll. obertoll.
also das kann es nicht sein.
vinum hat bei mir erstmal verschissen und fliegt bei nächster Gelegeheit vom System.

Nun erstmal ganz ruhig. Naja, ok, ich kann verstehen das Du ziemlich angepisst bist. Aber, ich kann mir nicht vorstellen das nun alles irgendwie verloren und inkonsistent ist, wenn dem so wäre, so müsste dies wirklich eine unglückliche Konstelation sein, oder vinum hat nen Bug (der so auch nicht verzeihbar wäre).

Wie wäre es Du schreibst Groggy eine mail? Der hat das Teil ja programmiert, spricht Deutsch (wohnt in Australien) und wird Dir sicher antworten: grog@lemis.com

Ansonsten, unter www.vinumvm.org steht nichts? Auch nicht unter www.google.de/groups gefunden?
 
hi,

ich kanns ihm ja mal schreiben.
aber ein lost+found mit 4800 verzeichnissen (der rest ist leer) und daten, wenn vorhanden, die einfach nicht mehr zu lesen sind (jpeg, zi, rar), macht mich halt "relativ" wütend :)

naja , ich recover mal weiter....
 
Du hast das Kapitel über vinum gelesen in seinem neuen Buch? Ist unter www.vinumvm.org einzusehen:

Recovering from drive failures

______________________________

One of the purposes of Vinum is to be able to recover from hardware problems.
If you have chosen a redundant storage configuration, the failure of a single
component will not stop the volume from working. In many cases, you can
replace the components without down time.

If a drive fails, perform the following steps:

1. Replace the physical drive.

2. Partition the new drive. Some restrictions apply:

o If you have hot-plugged the drive, it must have the same ID, the Vinum
drive must be on the same partition, and it must have the same size.



vinum.mm,v v4.18 (2003/04/02 06:46:15) (modified 5 Apr 2003, 00:51:16 UTC)






__________________________________________________ 244

244
o If you have had to stop the system to replace the drive, the old drive
will not be associated with a device name, and you can put it anywhere.
Create a Vinum partition that is at least large enough to take all the
subdisks in their original positions on the drive. Vinum currently does
not compact free space when replacing a drive. An easy way to ensure this
is to make the new drive at least as large as the old drive.

If you want to have this freedom with a hot-pluggable drive, you must stop
Vinum and restart it.

3. If you have restarted Vinum, create a new drive. For example, if the
replacement drive data3 is on the physical partition /dev/da3s1h, create a
configuration file, say configfile, with the single line

drive data3 device /dev/da3s1h

Then enter:

# vinum create configfile


4. Start the plexes that were down. For example, vinum list might show:

vinum -> l -r test
V test State: up Plexes: 2 Size: 30 MB
P test.p0 C State: up Subdisks: 1 Size: 30 MB
P test.p1 C State: faulty Subdisks: 1 Size: 30 MB
S test.p0.s0 State: up PO: 0 B Size: 30 MB
S test.p1.s0 State: obsolete PO: 0 B Size: 30 MB

vinum -> start test.p1.s0
Reviving test.p1.s0 in the background
vinum -> vinum[295]: reviving test.p1.s0 this message appears after the prompt
(some time later)
vinum[295]: test.p1.s0 is up



Failed boot disk
________________

If you're running your root file system on a Vinum volume, you can survive the
failure of the boot volume if it is mirrored with at least two concatenated
plexes each containing only one subdisk. Under normal circumstances, you can

vinum.mm,v v4.18 (2003/04/02 06:46:15) (modified 5 Apr 2003, 00:51:16 UTC)






__________________________________________________ 12: The Vinum Volume Manager

245
carry on running as if nothing had happened, but obviously you will no longer
be able to reboot from that disk. Instead, boot from the other disk.

The root file system also has individual UFS partitions, so you have a choice
of what you mount. For example, if your root file system has UFS partitions
/dev/da0s4a and /dev/da1s4a, you can mount either of these partitions or
/dev/vinum/root. Never mount more than one of them, otherwise you can cause
data corruption.

An even more insidious way to corrupt the root file system is to mount
/dev/da0s4a or /dev/da1s4a and modify it. In this case, the two partitions are
no longer the same, but there's no way for Vinum to know that. If this
happens, you must mark the other subdisk as crashed with the vinum stop
command.
 
hi,

ja haub ich gelesen gehabt, aber ich muss doch noch was zu raid5 loswerden.

Cold hat's zwar schon fast erfasst, aber die stärke von raid5 muss ich kurz nochma hervorheben, da falsch dargestellt.
die daten werde gleichmässig mit einem "paritybit" auf die platten verteilt, dadurch erspart man sich die parityplatte (das zum thema kosten).
sieht "ungefähr!" so aus:

platte1 platte2 platte3 platte4
1 2 3 parity
parity 3 2 1
2 3 parity 1
1 parity 3 2
... usw

dadurch kann jede festplatte ausfallen und dennoch bleibt das system konsistent, da die fehlenden information "errechnet" werden.
da beim schreiben diese parity-bits errechnet werden müssen, ist es nämlich genau umgekehrt:
langsames schreibrn, schnelles lesen!

daher haben hardware raid5 controller immer massig speicher und ne risc-cpu auf der platine.

also, was da passiert ist, geht an der eigentlichen bestimmung des raid5 vorbei. vinum hat in diesem falle leider einfach nur versagt.
 
Original geschrieben von marzl
hi,

ja haub ich gelesen gehabt, aber ich muss doch noch was zu raid5 loswerden.

Cold hat's zwar schon fast erfasst, aber die stärke von raid5 muss ich kurz nochma hervorheben, da falsch dargestellt.
die daten werde gleichmässig mit einem "paritybit" auf die platten verteilt, dadurch erspart man sich die parityplatte (das zum thema kosten).
sieht "ungefähr!" so aus:

platte1 platte2 platte3 platte4
1 2 3 parity
parity 3 2 1
2 3 parity 1
1 parity 3 2
... usw

dadurch kann jede festplatte ausfallen und dennoch bleibt das system konsistent, da die fehlenden information "errechnet" werden.
da beim schreiben diese parity-bits errechnet werden müssen, ist es nämlich genau umgekehrt:
langsames schreibrn, schnelles lesen!

daher haben hardware raid5 controller immer massig speicher und ne risc-cpu auf der platine.

also, was da passiert ist, geht an der eigentlichen bestimmung des raid5 vorbei. vinum hat in diesem falle leider einfach nur versagt.


Stimmt, aber es gilt nur dann wenn EINE Platte ausfällt. Bei zwei oder mehr ist es aus ... leider.

Gruß

CW
 
Original geschrieben von marzl
und mir is ja auch nur eine ausgefallen....
......ggggggGGGGGGGGGRRRRRRRRRrrrrrrr.....

Dann solltest du deinen Thread eher Leidensbericht nennen :D

Gruß und trotzdem viel Erfolg mit dem Neuaufbau bzw. Restaurierung

CW
 
EHRENRETTUNG

Soooooo,
hab jetzt mal n bissel rumgeforscht und bin auf folgendes gestossen.
wenn ich rumkotzen kann, kann ich auch wieder aufwischen.

wenn man ein raid5 (tutorial folgt) einrichtet, dann kann man es nicht laufen lassen und vergessen.
man MUSS regelmässig (am besten als cronjob) die paritybits überprüfen "checkparity"
und ggf neu aufbauen, bzw korrigieren "rebuildparity".
das hab ich natürlich nicht getan. :(
leider wird in der man-page nicht wirklich auf die notwendigkeit hingewiesen, es wird lediglich der befehl erläutert.
also: auf ein neues!
 
marzl schrieb:
Hallo Leutz,

ich hab n Hals. :(
Ich hatte doch mal erwähnt das ich Vinum für mein Raid5 benutze.
Soweit so gut, hat ja auch alles prima funktioniert, ABER:
Jetzt ist es tatsächlich passiert: Eine Platte hat den Geist aufgegeben. Peng.
Also Rechner runter, Festplatte raus, Rechner hoch.
Nach meinem Verständnis über Raid5 sollte jetzt alles normal weiterfunktionieren, .... dem ist aber nocht so.

Ich habe auch ein RAID-1 auf meinem Server laufen, eine Beschreibung meines Vorgehens habe ich ins Netz gestellt:
http://os4.org/os/bsd/freebsd/vinum.html

Mir ist auch schon eine von diesen "berühmten" 30GB-Platten darin abgeraucht.
Seit dem habe ich DMA abgeschaltet:
bash-2.05b# cat /boot/loader.conf.local
hw.ata.ata_dma=0
hw.ata.atapi_dma=0

Seit dem ist mir keine mehr abgeraucht. Ich habe es damals auch nicht hinbekommen eine neue wieder reinzukonfen. Nur eines darf man (nach meinen Erfahrungen) NICHT! Die defekte Platte einfach so ausbauen... Erst ein Backup! Dann die MAN lesen... :cool:
 
Zurück
Oben