From owner-freebsd-questions@FreeBSD.ORG Fri Mar 19 14:27:44 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69F2A16A4CE for ; Fri, 19 Mar 2004 14:27:44 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBE9843D1F for ; Fri, 19 Mar 2004 14:27:43 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id AC19D2BDA6 for ; Sat, 20 Mar 2004 09:27:40 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id A3B3D51208; Sat, 20 Mar 2004 08:57:38 +1030 (CST) Date: Sat, 20 Mar 2004 08:57:38 +1030 From: Greg 'groggy' Lehey To: Lewis Thompson Message-ID: <20040319222738.GQ21807@wantadilla.lemis.com> References: <20040316020000.GA846@lewiz.org> <20040316111325.GB742@adelaide.lemis.com> <20040316172526.GB1236@lewiz.org> <20040318025602.GZ58155@wantadilla.lemis.com> <20040319030334.GA1985@lewiz.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MT9SxUWSsctiw0kG" Content-Disposition: inline In-Reply-To: <20040319030334.GA1985@lewiz.org> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: questions@freebsd.org Subject: Re: Vinum, replaced disk -- fsck error. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 22:27:44 -0000 --MT9SxUWSsctiw0kG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Friday, 19 March 2004 at 3:03:34 +0000, Lewis Thompson wrote: > On Thu, Mar 18, 2004 at 01:26:02PM +1030, Greg 'groggy' Lehey wrote: >> On Tuesday, 16 March 2004 at 17:25:26 +0000, Lewis Thompson wrote: >>> 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. >> >> But not to me. > > I've included more detailed errors neared to the end of this email :) > >> I was really thinking of "What to do if you have problems with Vinum" >> at http://www.vinumvm.org/vinum/how-to-debug.html. > > Okay, I did actually do my best to follow this but maybe got > sidetracked. I'm just going to bullet point these now so I don't miss > any of them out. > > * Problems: ``dd'' cloned disk ``does not work'' (i.e. gstat shows no > activity on the cloned disk during reading of files). What command did you enter? What happened on the command line? > Also see previous emails. You can't really expect me to go digging for them. > * Changes to system: Originally vinum ran on 4.9-STABLE. This worked > but had periodic ``disk crashes'' (i.e. vinum states disk as offline). > I don't think this is the problem as the same behaviour happens with > 5.2.1-p1 using the original dodgy disk (only GEOM removes it instead > of vinum). It looks like part of the problem to me. It seems that you have a flaky disk. Is that correct? > * Vinum list (excuse lack of wrapping). On the contrary, it shouldn't be wrapped. I don't see anything in this list that hasn't started. Is it correct that volume "data" only has one plex? > * /var/log/messages extract. I originally started vinum a long while > before, I included this entry too (excuse wrapping): > > Mar 17 23:33:57 amnesia kernel: vinum: loaded > Mar 17 23:34:00 amnesia kernel: vinum: reading configuration from /dev/ad1s1h > Mar 17 23:34:00 amnesia kernel: vinum: updating configuration from /dev/ad2s1h > Mar 17 23:34:00 amnesia kernel: vinum: updating configuration from /dev/ad3s1h > Mar 19 02:49:26 amnesia kernel: WARNING: /mnt/data was not properly dismounted > Mar 19 02:52:15 amnesia kernel: vinum: null rqg > > This seems a little odd to me -- previously I had not had a null rqg > error. This is certainly an interesting one. > I think maybe I didn't test it enough. Since these are mostly avi > files I can tell if they are broken on not by seeing if they have an > index -- last time they all played but many without indexes. > Nothing has changed since then; maybe I wasn't being thorough > enough? I'm wondering if the problem isn't at least partially due to the flaky disk. The "null rqg" message indicates that a request couldn't be mapped. I'd really need a dump from this point, if the problem is repeatable. Let me know and I'll send you a patch. >>> During the process a number (maybe eight to ten) I/O errors were >>> reported. > > These were dd errors. I didn't write these down at the time (silly of > me) and I'm not sure they even go into any log files. However, I have > found the exact error messages I got (although the offsets are wrong). > If required I will re-run dd and provide the full errors. > > The messages were: > > dd: reading `/dev/ad3': Input/output error Hmm. Why are you running against /dev/ad3? Why are you using dd at all? In any case, I would expect error messages in /var/log/messages at this point. > In a reply to my original question you stated that ``dd if=ad3 of=ad1 > bs=8192 conv=noerror'' ``may or may not work, depending on details you > haven't reported.'' Do these detailed errors help at all? A little. They tell me that the drive is flaky. I'd expect to see the error messages in /var/log/messages, though. > I just read a thread[1] about dd that makes me wonder whether it > would have been. The only reference I see there is to the current thread. At least it gave me the background. > I think that's everything. I'm just going to include some other stuff > from earlier emails that has been chopped earlier. Maybe it has some > relevance: > > = fsck_ufs /dev/vinum/data gives the following message: > = ** /dev/vinum/data > = cannot alloc 4316869296 bytes for inphead Yes, this is almost certainly due to incorrect copying. Probably the conv=noerror is to blame for that. I suspect that, unless you can read the sections of the volume that appear to be causing the fsck problems, you may be out of luck. About the only thing you could try is to mount the volume read-only without fsck, and then copy what data you can elsewhere. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger grog@FreeBSD.org for PGP public key. See complete headers for address and phone numbers. --MT9SxUWSsctiw0kG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFAW3PaIubykFB6QiMRAjGhAJ9uoNUXiS2WUX76t2aX6khESUF/yQCdHjUB CMcrmLPuwukH6jBqD3JwA2U= =htiL -----END PGP SIGNATURE----- --MT9SxUWSsctiw0kG--