Re: vinum mit defekte Platte im raid1 (concat) - wie restore? (2. Nachtrag)

From: Oskar Eyb <oskar(at)solls.net>
Date: Tue, 19 Aug 2003 10:28:56 +0200

On Tue, Aug 19, 2003 at 12:38:04PM +0930, Greg 'groggy' Lehey wrote:

> [Format recovered--see http://www.lemis.com/email/email-format.html]
>
> Überlange Zeilen

Sorry, in diesem Webmail hatte ich das nicht wirklich unter Kontrolle.
Jetzt stimmt es wieder.

 
> On Monday, 18 August 2003 at 15:52:26 +0200, Oskar Eyb wrote:
> >> moooment, jetzt bin ich leicht verwirrt:
> >> ich verstehe nicht, warum die stripesets (tmp, data2), die auch auf ad0 liegen,
> >> wo fsck die fehler meldet, augenscheinlich FUNKTIONIEREN.
> >
> > Nun habe ich kurzerhand ad0s1a mit newfs formatieren lassen,
>
> Warum denn das? Das ist so gut wie nie notwendig.

Ich wusste mir nicht anders zu helfen, zudem diese Partition nicht
gebraucht wurde. (Oder doch, daher auch die inkonsistenten kernel -
world, vermutlich, s.u.)

> > und nun auch fsck machen keine Fehler.
>
> Ohne nähere Angaben ist diese Aussage bedeutungslos.

Fsck auf ad0s1a brachte eine ganze Latte an Fehler, weswegen ich an
einen Plattenfehler dachte. Mich machte dann aber stutzig, das vinum
doch keine Problem mit dem drive hat (auf ad0 gibt es auch ein
vinum-Bereich). Nach dem Formatieren der ufs-Partition mekkerte fsck
nichtmehr.

> > Da das rootfs auf ad4s1a liegt musste ich am loader-prompt die
> > Stelle angeben
>
> >
> > boot: ad(4,a)/kernel

> Hängt vom großen Bild ab, das ich nicht sehe.
> http://www.vinumvm.org/vinum/how-to-debug.html,

OK, nun siehts folgendermaßen aus:

vinum l -r alcavar
V alcavar State: up Plexes: 2 Size: 3072MB
P alcavar.p0 C State: up Subdisks: 1 Size: 3072MB
P alcavar.p1 C State: up Subdisks: 1 Size: 3072MB
S alcavar.p0.s0 State: up PO: 0 B Size: 3072MB
S alcavar.p1.s0 State: up PO: 0 B Size: 3072MB

# fsck /dev/vinum/alcavar
** /dev/vinum/alcavar
BAD SUPER BLOCK: MAGIC NUMBER WRONG
/dev/vinum/alcavar: CANNOT FIGURE OUT FILE SYSTEM PARTITION

Im Rechner an den onboard-IDE-Schnittstellen hängt je eine Festplatte
(1x 80GB und 1x 20GB) die mit vinum in in einem stripe sind.

ad0 und ad3, etwas langsamer (UDMA33) als die anderen beiden am
Promise-Kontroller (UDMA100). Wegen diesem Geschwindigkeitsunterschied
möchte ich das root-fs auf ad4s1a, (mit dump auf ad6s1a gespiegelt).

Ich befürchte nun, das dieser Unterschied auf dem root-fs kaum bis nichts
bringt, zumal die anderen Partitionen usr, var (zZ wieder nicht), tmp,
daten sowiso auf anderen Festplatten sind. Am einfachsten wäre es wohl
das root-fs einfach auf ad0s1a zu dump´en.

Beim Booten seit dem "crash" (was auch immer das nun genau war?!) wurde
der kernel auf ad0 gesucht, also korrigierte ich das mit Eingabe von
" ad(0,a)/kernel " am loader-Prompt.

Daraufhin wurde aber der falsche Kernel gebootet:

FreeBSD 4.8-STABLE-20030712-JPSNAP #0: Sat Jul 12 01:54:41 GMT 2003
    root(at)tora.jp.freebsd.org:/usr/obj/usr/src/sys/GENERIC

Ich erstellte in der Zwischenzeit natürlich einen neueren.

Nachdem ich auf die Idee gekommen bin doch mal ad4s1a auf ad6s1a (steht
nur per noauto in der fstab drin) zu dumpen wurde der korrekte Kernel
gebootet. (Aber immernoch nach Eingabe von " ad(0,a)/kernel " am
loader-Prompt.

- Die IDE-Bus-Geschindigkeit UDMA 33 / UDMA 100 ist für die kleine
  root-partition irrelevant? (Dann würde ich einfach ad0s1a als / nehmen)

- der, wie erfährt der loader das er von ad4s1a den kernel holen soll?
  Warum wurde er dann trotzdem von ad6s1a gestartet?

- Und wie komme ich an die Daten von /dev/vínum/alcavar wieder ran?
  (s. fsck / mount - Fehler oben)

# mount
/dev/ad4s1a on / (ufs, local)
[...]

# Device Mountpoint FStype Options Dump Pass
/dev/ad6s1b none swap sw 00
/dev/ad4s1b none swap sw 00
/dev/ad0s1b none swap sw 00

/dev/ad4s1a / ufs rw 11
/dev/ad6s1a /vol/root-b ufs rw,noauto 11

#/dev/vinum/alcavar /var ufs rw 22
/dev/vinum/alcausr /usr ufs rw 22
/dev/vinum/alcajail /jail ufs rw 22
/dev/vinum/alcatmp /tmp ufs rw 22
/dev/vinum/alcadata1 /vol/alcadata1 ufs rw 22
/dev/vinum/alcadata2 /vol/alcadata2 ufs rw 22

Grüße,

-- 
Oskar
To Unsubscribe: send mail to majordomo.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 19 Aug 2003 - 10:29:36 CEST

search this site