Re: fsck auf vinum volume: Cannot find file system superblock & more :(

On Wed, Feb 02, 2005 at 08:11:18PM +0100, Oskar Eyb wrote:
> Hallo!
>
> mich führt wieder ein Problem mit Vinum zu euch:)
>
> Nach Einfrieren eines 5.3-RELEASE-p2 Systems (Screensaver, Netzwerk,
> ...) und einem Neustart waren die beiden Plexe
>
> S alcadata1.p0.s0 State: up D: alca80gb1 Size: 49 GB
> S alcadata1.p1.s0 State: up D: alca80gb2 Size: 49 GB
>
> auf "stale".
>
> Mit 'start alcadata1.p0.s0' und 'start alcadata1.p1.s0' bekam ich sie
> wieder "up". Den zweiten Befehl habe ich nach Beendigung des
> (R)etrieve-Vorgangs des ersteren gegeben. Die beiden Plexe brauchten
> einige Zeit, bis das abgeschlossen war.

Du wirst das jetzt wohl nicht hören wollen, aber das klingt nicht gut.
Wenn beide Plex down waren - wovon sollte der erste, den du gestartet
hast denn syncen können?
Meine vermutung ist, dass der erste sich mit nullen gefüllt hat und der
zweite darauf syncronisiert wurde - immerhin hat der erste start deiner
Aussage nach ja recht lange gebraucht, obwohl nichts zu tun war.
Du kannst ja mal per dd ein paar Blöcke von dem Volume lesen um
meine Befürchtung zu prüfen.
Ich starte bei so einem Fall den ersten Plex immer per setstate und
dabei muss man sich vorher informieren, welcher Plex zuletzt noch lief.
Ein Ausfall aller Redundanz ist bei RAID Systemen eigendlich meistens
Handarbeit und das finde ich persönlich auch gut so, weil Automatismen
nicht immer das richtige tun.

> Doch auch danach schlägt die Benutzung des volumes fehl:
>
> # fsck /dev/vinum/alcadata1
> ** /dev/vinum/alcadata1
> Cannot find file system superblock
> ioctl (GCINFO): Inappropriate ioctl for device
> fsck_ufs: /dev/vinum/alcadata1: can't read disk label
>
>
> Alle drives und alle anderen volumes sind 'up' und benutzbar.
>
>
> Mir deucht, das ich mich mit der Benutzung von vinum (anstatt gvinum -
> bzw überhaupt) auf einem geupgradeten 5.3 auf dünnes Eis begeben habe.
>
> Wie macht mans richtig,- und- noch interessanter, gibts Chancen, wenn
> ja, über welche Wege, an alcadata1 as-it-is heranzukommen?

Richtig wäre es dass deine Redundanz nicht an unredundanter Versorgung
hängt.
Wenn die Plexe wirklich genulled sind bleibt dir nur noch dein Backup.

> in /var/log/message habe ich noch was gefunden:
>
> Feb 2 14:35:44 q kernel: ad4: TIMEOUT - WRITE_DMA retrying (2 retries
> left) LBA=129384840
>
> Feb 2 14:35:44 q kernel: ad6: TIMEOUT - WRITE_DMA retrying (2 retries
> left) LBA=129384840
>
> Feb 2 14:35:59 q kernel: ad4: FAILURE - WRITE_DMA timed out
> Feb 2 14:35:59 q kernel: vinum: alcadata1.p0.s0 is stale by force
> Feb 2 14:35:59 q kernel: vinum: alcadata1.p0 is faulty
> Feb 2 14:35:59 q kernel: fatal :alcadata1.p0.s0 write error, block
> 124883273 for 8192 bytes
>
> Feb 2 14:35:59 q kernel: alcadata1.p0.s0: user buffer block 72454208
> for 8192 bytes
>
> Feb 2 14:35:59 q kernel: ad6: FAILURE - WRITE_DMA timed out
> Feb 2 14:35:59 q kernel: vinum: alcadata1.p1.s0 is stale by force
> Feb 2 14:35:59 q kernel: vinum: alcadata1.p1 is faulty
> Feb 2 14:35:59 q kernel: vinum: alcadata1 is down
> Feb 2 14:35:59 q kernel: fatal :alcadata1.p1.s0 write error, block
> 124883273 for 8192 bytes

Ja - beide waren gleichzeitig weg.
Da sich die Platten nicht den gleichen Kanal zu teilen scheinen wirst
du wohl einen Ausfall der Stromversorgung haben.

> Feb 2 14:35:59 q kernel: alcadata1.p1.s0: user buffer block 72454208
> for 8192 bytes
>
> Feb 2 14:42:36 q kernel: Interrupt storm detected on "irq12: atapci1";
> throttling interrupt source
>
>
>
> Die Sache war schon heute Mittag... der Crash dann erst am Abend.
> Eine automatische Benachtichtigung wäre fein gewesen.

Sollte der daily job aus den Logs heraus machen.
Immerhin sind das ja Kernel Nachrichten.

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