Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jun 2005 15:37:56 +0200
From:      Gareth Bailey <gjbailey@gmail.com>
To:        freebsd-questions <freebsd-questions@freebsd.org>
Subject:   Re: Vinum subdisk crash
Message-ID:  <48a5f32a05063006376728d52b@mail.gmail.com>
In-Reply-To: <48a5f32a0506300250402d4514@mail.gmail.com>
References:  <48a5f32a0506300250402d4514@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello everyone,

Just to add, I had to type out the above message manually since I can't get=
=20
access to anything with the crashed subdisk on /usr.
With regard to Greg's requests for information when reporting vinum problem=
s=20
as stated on vinumvm.org <http://vinumvm.org>'s website, I can provide the=
=20
following info:

What problems are you having?
My usr.p0.s0 subdisk reports a 'crashed' status

Which version of FreeBSD are you running?
4.10 Stable

Have you made any changes to the system sources, including Vinum?
No

Supply the output of the *vinum list* command. If you can't start Vinum,=20
supply the on-disk configuration, as described below. If you can't start=20
Vinum,
then (and only then) send a copy of the configuration file.
I can't get anything off the system, and its too long to type out! (I have=
=20
the same layout as in the Van Valzah article.)

Supply an *extract* of the Vinum history file. Unless you have explicitly=
=20
renamed it, it will be */var/log/vinum_history*. This file can get very big=
;=20
please limit it to the time around when you have the problems. Each line=20
contains a timestamp at the beginning, so you will have no difficulty in=20
establishing which data is of relevance.
I will summarise the tail of vinum_history (doesn't seem to provide any=20
interesting info):
30 Jun 2005 ***vinum started***
30 Jun 2005 list
30 Jun 2005 ***vinum started***
30 Jun 2005 dumpconfig

Supply an *extract* of the file */var/log/messages*. Restrict the extract t=
o=20
the same time frame as the history file. Again, each line contains a=20
timestamp at the beginning, so you will have no difficulty in establishing=
=20
which data is of relevance.
Again, I will summarise the tail contents of messages:
30 Jun server /kernel: ad0s1h: hard error reading fsbn 59814344 of=20
29126985-29127080 (ad0s1 bn 59814344; cn 3723 tn 69 sn 2) trying PIO mode
30 Jun server /kernel: ad0s1h: hard error reading fsbn 59814344 of=20
29126985-29127080 (ad0s1 bn 59814344; cn 3723 tn 69 sn 2) status=3D59 error=
=3D40
30 Jun server /kernel: vinum: usr.p0.s0 is crashed by force
30 Jun server /kernel: vinum: usr.p0 is faulty
30 Jun server /kernel: vinum: usr is down
30 Jun server /kernel: fatal:usr.p0.s0 read error, block 29126985 for 49152=
=20
bytes
30 Jun server /kernel: usr.p0.s0: user buffer block 28102720 for 49152 byte=
s

If you have a crash, please supply a backtrace from the dump analysis as=20
discussed below under Kernel Panics. Please don't delete the crash dump; it=
=20
may be needed for further analysis.
I'm not sure if a kernel panic occurred?

I hope this information helps, and that someone can give me some advice!=20

Cheers,
Gareth

On 6/30/05, Gareth Bailey <gjbailey@gmail.com> wrote:
>=20
> Hello,
>=20
> It appears that one of the vinum subdisks on my server has crashed. On=20
> rebooting I get the following message:
>=20
>=20
> <-- start message -->
>=20
> Warning: defective objects
>=20
> V usr State:down Plexes:2 Size:37GB
> P usr.p0 C State:faulty Subdisks:1 Size:37GB
> P usr.p1 C State:faulty Subdisks:1 Size:37GB
> S usr.p0.s0 State:crashed P0:0 B Size:37GB
> S usr.p1.s0 State:stale P0:0 B Size:37GB
>=20
> [some fsck messages]
> Can't open /dev/vinum/usr: Input/output error
> [some more fsck messages]
> THE FOLLOWING FILE SYSTEM HAD AN UNEXPEXTED INCONSISTENCY:
> /dev/vinum/usr (/usr)
> Automatic file system checj failed . . . help!
> Enter full pathname of shell....
>=20
> <-- end message -->
>=20
> I have a straight forward configuration based on the "Bootstrapping Vinum=
:=20
> A Foundation for Reliable Servers" article by Robert Van Valzah.
> What could have caused this? The disks are pretty new. Please advise on=
=20
> the quickest route to getting our server back online.
>=20
> Much appreciated,
>=20
> Gareth Bailey



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48a5f32a05063006376728d52b>