On Tue, Mar 16, 2004 at 07:13:25PM +0800, Greg Lehey wrote:
> On Tuesday, 16 March 2004 at  2:00:00 +0000, Lewis Thompson wrote:
> > I had a failed disk in my RAID-0 Vinum array.  This was a physical disk
> > problem and in an attempt to recover as much data as possible I dd'ed it
> > to another disk (dd if=ad3 of=ad1 bs=8192 conv=noerror).
> This may or may not work, depending on details you haven't reported.

I can't think of anything else.  Originally I ran dd without the
conv=noerror and it stopped at around 25GB (the disk is a 100GB).  The
destination disk is 123GB but to my knowledge that is acceptable for dd.

  During the process a number (maybe eight to ten) I/O errors were
reported.  Previously I believe reading data from these areas on the
disk caused Vinum to lose the disk (under 4-STABLE), I presume this was
by design, or unavoidable.  Under 5.2.1-p1 GEOM removed the disk
totally.  The dd was done using the rescue disk from 4.9-RELEASE (to
avoid GEOM).

> > I can actually start vinum and mount the RAID-0 array with no
> > trouble (Vinum reports no errors I can see).

Since I wrote this I posted a reply stating that whatever files I try
and open (mostly my personal video collection), gstat reports no
activity from ad3 -- the replaced disk.  A lot of the indexes from the
AVIs are dead.

> > I don't really know how I can test the integrity of files from the
> > replaced disk...
> A good start would be to read the documentation at
> http://www.vinumvm.org/.

Unresolved bugs, 27 Feb 2000. -- this doesn't seem to have applied.
When I started vinum (I previously ran dumpconfig) with create -f
myconfig my data plex (comprised 2*120GB and the replaced 100GB) was
listed as up.

  At this point I tried the fsck with an error about invalid
superblocks, so I restored those on /dev/vinum/data with tunefs -A.
fsck then failed with the ``cannot alloc 4316869296 bytes for inphead''

  I've read the replacing a failed Vinum drive a couple of times now but
I still don't quite understand it.  Does this apply to RAID-0?  Surely I
can't revive a concatenated array?  I assume this must only apply to
RAID-1 and RAID-5 (and maybe some of the others in between I know
nothing about).

  Reading more about debugging vinum I found this oddity (maybe it
isn't, since it's actually before the config):

[EMAIL PROTECTED] root state upvinumdrive0:     <-- ad1.config
[EMAIL PROTECTED] root state upvinumdrive1:     <-- ad2.config

  diff on ad2.config and ad3.config instead gives:

[EMAIL PROTECTED] root state upvinumdrive1:     <-- ad2.config
> IN VINOpurple.lewiz.orgvinumdrive2?;[EMAIL PROTECTED] root state up
^-- ad3.config

  There are a few extra chars different after the vinumdrive line, from
those in ad1 and ad2.  This probably isn't anything?

  I've stopped short of compiling vinum with debugging options (this was
under kernel panics, which I'm not having).  I'll go ahead and do this
though if it can provide any more info.

  There is nothing of any value in /var/log/vinum_history (but I've
cp'd it to http://www2.cs.man.ac.uk/~thompsl3/vinum_history just in
case).  If you look at this file you can see I messed with create -f a
lot.  This was because the old disk didn't seem to like storing the
on-disk configuration.  The new disk seems to do this.

> > worked fine.  However (and this is my real problem), fsck_ufs
> > /dev/vinum/data gives the following message:
> >
> > ** /dev/vinum/data
> > cannot alloc 4316869296 bytes for inphead
> >
> Possibly there are log messages that go with this message.  It
> indicates to me that there's something seriously wrong in some data
> structure, and that fsck is asking for a ridiculous amount of memory
> as a result.

No errors appear in any of the files in /var/log (I checked them all,
just in case).

  Thanks very much,


I was so much older then, I'm younger than that now.  --Bob Dylan, 1964.
-| msn:[EMAIL PROTECTED] | jabber:[EMAIL PROTECTED] | url:www.lewiz.org |-

Attachment: pgp00000.pgp
Description: PGP signature

Reply via email to