Date: Tue, 16 Mar 2004 17:25:26 +0000 From: Lewis Thompson <lewiz@fajita.org> To: Greg Lehey <grog@FreeBSD.org> Cc: questions@freebsd.org Subject: Re: Vinum, replaced disk -- fsck error. Message-ID: <20040316172526.GB1236@lewiz.org> In-Reply-To: <20040316111325.GB742@adelaide.lemis.com> References: <20040316020000.GA846@lewiz.org> <20040316111325.GB742@adelaide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3Dad3 of=3Dad1 bs=3D8192 conv=3Dnoerror). >=20 > 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=3Dnoerror 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... >=20 > 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'' error. 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): ?aV@7volume root state upvinumdrive0: <-- ad1.config --- ?DaV@volume root state upvinumdrive1: <-- ad2.config diff on ad2.config and ad3.config instead gives: ?DaV@volume root state upvinumdrive1: <-- ad2.config --- > IN VINOpurple.lewiz.orgvinumdrive2?;aV@gTvolume 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 > > > > ***** FILE SYSTEM STILL DIRTY ***** >=20 > 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, -lewiz. --=20 I was so much older then, I'm younger than that now. --Bob Dylan, 1964. ------------------------------------------------------------------------ -| msn:purple@lewiz.net | jabber:lewiz@jabber.org | url:www.lewiz.org |- --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAVziGItq0KFQv7T8RAlfqAKDvjfOhz6YraIPiRxtz+pm9QphlvwCg9rbp 3tyjcNjYJ6W8324lyLttcTY= =6mKN -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040316172526.GB1236>