Re: Vinum Spielereien

On Friday, 30 January 2004 at 19:45:31 +0100, Oliver Lehmann wrote:
> Hallo,
>
> ich hab mich mal wieder dazu "aufgerafft" um mit Vinum zu spielen.
> 4 1GB Platten, RAID-5
>
> root(at)nudel olivleh1> vinum l
> 6 drives:
> D d1 State: up /dev/da1s1d A: 0/2008 MB (0%)
> D d2 State: up /dev/da2s1d A: 0/2008 MB (0%)
> D d3 State: up /dev/da3s1d A: 0/1004 MB (0%)
> D d4 State: up /dev/da4s1d A: 0/1004 MB (0%)
> D d5 State: up /dev/da5s1d A: 0/1004 MB (0%)
> D d6 State: up /dev/da6s1d A: 0/1004 MB (0%)
> D d7 State: referenced /dev/da7s1d A: 0/0 MB

Wundert Dich dieser letzte Eintrag nicht? Mich schon: Ein
"referenced" Drive ist eben deswegen referenced, weil Vinum dafür
keine Platte kennt.

> Von d6 den Stromstecker rausgezogen (Ich weiss, ich weiss -
> Stromschwankungen sind nicht toll. Die anderen Drives waren aber
> still. Und ich kann einen Plattenausfall auch nicht anders
> simulieren)

Gut, Du könntest auch das Datenkabel ziehen.

> (da6:sym0:0:3:0): Synchronize cache failed, status == 0x4a, scsi status == 0x0
> (da6:sym0:0:3:0): removing device entry
> GEOM: destroy disk da6 dp=0xc2df8450
>
> Nach dem rausziehen, und einem ls auf den Mountpoint:
>
> root(at)nudel olivleh1> vinum l
> 6 drives:
> ...
> D d6 State: down /dev/da6s1d A: 0/1004 MB (0%)

... wie zu erwarten wäre.

> Die selbe Platte dann wieder rangehangen, ein camcontrol rescan.
>
> root(at)nudel olivleh1> camcontrol rescan 1
> Re-scan of bus 1 was successful

Hier wäre interessant zu wissen, ob Dein da6 wieder erschienen ist.

> root(at)nudel olivleh1> camcontrol devlist -v
> scbus0 on ahc0 bus 0:
> <SEAGATE ST31200N 8590> at scbus1 target 3 lun 0 (pass7,da6)

Sieht zwar danach aus, muss aber nicht sein. Von da7 sieht es so aus,
dass Du schon andere Spielereien gemacht hast. Eventuell ist hier
etwas anderes passiert. Ist das jetzt die richtige Platte?

> root(at)nudel olivleh1> vinum start lvmr5.p0.s3
> Can't start lvmr5.p0.s3: Drive is down (5)

Hmm. Nicht sonderlich aussagefähig, zugegeben.

> Was nun?

Syslog-Meldungen?

> root(at)nudel olivleh1> vinum stop
> Can't unload vinum: No such file or directory
> root(at)nudel olivleh1> vinum start
>
> Und nun haengt es... wie auch mein ls...

Dafür müssten wir wissen, wo's hängt. Du solltest einen Dump ziehen.

> Sorry, aber kann man sowas ueberhaupt semi-produktiv einsetzen? Ist
> ein FreeBSD 5.2-REL

Ich habe in der Vergangenheit einige Probleme mit Plattenausfall
gehabt. In jedem Fall war's ein Problem des Plattentreibers. Im
vorliegenden Fall kann ich mir auch nicht vorstellen, wie das ein
Vinum-Problem sein könnte.

Mit GEOM hat sich ohnehin alles geändert. Wenn ich mal Zeit haben
sollte (nicht bald: Ich fahre gleich für zwei Wochen in Urlaub) werde
ich ein bisschen damit 'rumspielen.

On Friday, 30 January 2004 at 20:42:15 +0100, Oliver Lehmann wrote:
> Oliver Lehmann wrote:
>
>>
>> root(at)nudel olivleh1> vinum stop
>> Can't unload vinum: No such file or directory
>> root(at)nudel olivleh1> vinum start
>>
>> Und nun haengt es... wie auch mein ls... Sorry, aber kann man sowas
>> ueberhaupt semi-produktiv einsetzen? Ist ein FreeBSD 5.2-REL
>
> Da dann auch kein Login mehr moeglich war, blieb mir leider nichts
> anderes als ein Kaltstart uebrig (Ctrl+Alt+Del lokal ging auch nicht)
>
> Nach dem boot dann:
>
> root(at)nudel /root> vinum start
> root(at)nudel /root> vinum start lvmr5.p0.s3
> vinum[597]: reviving lvmr5.p0.s3
> Reviving lvmr5.p0.s3 in the background
> [...]
> vinum[597]: lvmr5.p0.s3 is up

Wie lange hat das gedauert? In welchem Zustand war die Subdisk zuvor?

> root(at)nudel /root> fsck /dev/vinum/lvmr5
> ** /dev/vinum/lvmr5
> ** Last Mounted on /mnt/lvmr5
> ** Phase 1 - Check Blocks and Sizes
> ** Phase 2 - Check Pathnames
> ** Phase 3 - Check Connectivity
> ** Phase 4 - Check Reference Counts
> ** Phase 5 - Check Cyl groups
> 3 files, 5010 used, 1486773 free (21 frags, 185844 blocks, 0.0% fragmentation)
>
> ***** FILE SYSTEM MARKED CLEAN *****
> root(at)nudel /root> mount /mnt/lvmr5
> root(at)nudel /root> md5 /mnt/lvmr5/test.dd
> MD5 (/mnt/lvmr5/test.dd) = 1a3c366e6c5ee58c92884b77a1084b52
> root(at)nudel /root> cat /usr/test.dd.md5sum
> MD5 (/mnt/lvmr5/test.dd) = 1a3c366e6c5ee58c92884b77a1084b52
> root(at)nudel /root>
>
> Die md5-Checksumme der Datei hatte ich vor der Spielerei mal
> genommen.

Also, wenn ich das richtig verstehe, ist alles wieder gut
hochgekommen, richtig? Das könntest Du auch gleich sagen.

> Ist dieses Verhalten normal das das System stehen bleibt?

Habe ich erlebt. Wünschenswert ist das Verhalten natürlich nicht.

> Ich mein, ich kann so ja auch SCSI devices entfernen hinzufuegen etc
> pp. und GEOM hat das ja auch mitbekommen. Sogar vinum... wiso haengt
> sich dann das System auf?

Wer weiß? Ich vermute, dass es wieder mal im Treiber (also auch nicht
in GEOM) steckt. Zuerst müssen wir aber den Dump sehen.

Greg

--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
See complete headers for address and phone numbers.

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 30 Jan 2004 - 22:31:54 CET