From owner-freebsd-questions Tue Nov 2 7: 3:18 1999 Delivered-To: freebsd-questions@freebsd.org Received: from mojave.sitaranetworks.com (mojave.sitaranetworks.com [199.103.141.157]) by hub.freebsd.org (Postfix) with ESMTP id 1F4951542F for ; Tue, 2 Nov 1999 07:03:07 -0800 (PST) (envelope-from grog@lemis.com) Message-ID: <19991102085310.03762@mojave.sitaranetworks.com> Date: Tue, 2 Nov 1999 08:53:10 -0500 From: Greg Lehey To: cjclark@home.com, FreeBSD Questions , Greg@cc942873-a.ewndsr1.nj.home.com, Lehey@cc942873-a.ewndsr1.nj.home.com Subject: Re: Recovering vinum Volume Reply-To: Greg Lehey References: <199911020152.UAA03093@cc942873-a.ewndsr1.nj.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <199911020152.UAA03093@cc942873-a.ewndsr1.nj.home.com>; from Crist J. Clark on Mon, Nov 01, 1999 at 08:52:39PM -0500 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, 1 November 1999 at 20:52:39 -0500, Crist J. Clark wrote: > I was playing around with adding some SCSI HDDs to a machine. The > machine already had two drives which are configured into a single > vinum volume. Adding the new drives caused some problems (possibly > hardware problems with wires just not connected right, or a SCSI ID of > 0 seemed like it may have flipped out the aha0 driver, possible?). One > of the vinum drives was never seen at those startup attempts. Just for > completeness, before adding the new hardware, I first umount'ed the > vinum volume then issued a 'vinum stop'. > > Now, from what I gather from the manpage, if the devices do not come > up properly, vinum will not write to them. So is the data on those > drives still there? Yes. If nothing writes to them, it doesn't change :-) > I took the system back to its old hardware configuration, but vinum > still does not come up. It reports two of the subdisks as "crashed" > and one as "up." From what it says about "crashed" on vinum(4) this > _seems_ tosay my data is still there, Correct. > but I'm not sure how to get at it. A 'stop' and 'start' does not > seem to fix it, and anything stronger than that has foreboding > warnings in the manpages and could cause me to lose the data. I'd > like to be sure of what to try before I do this. You don't give the exact commands. What does 'vinum start scsivol.p0.s1' say? If that doesn't work, I have deep magic which will, but I don't want to use it indiscriminately. > # vinum l > Configuration summary > > Drives: 3 (4 configured) > Volumes: 1 (4 configured) > Plexes: 1 (8 configured) > Subdisks: 3 (16 configured) > > D scsi1 State: up Device /dev/da1h Avail: 0/1003 MB (0%) > D scsi2 State: up Device /dev/da2g Avail: 13/1016 MB (1%) > D scsi3 State: up Device /dev/da2h Avail: 13/1016 MB (1%) > > V scsivol State: down Plexes: 1 Size: 3009 MB > > P scsivol.p0 S State: faulty Subdisks: 3 Size: 3009 MB > > S scsivol.p0.s0 State: crashed PO: 0 B Size: 1003 MB > S scsivol.p0.s1 State: up PO: 512 kB Size: 1003 MB > S scsivol.p0.s2 State: crashed PO: 1024 kB Size: 1003 MB > > Now for the 'messages' output, this first set is from when vinum was > stopped, then restarted after the malconfigured SCSI setup was put in > place, > > Nov 1 17:31:54 backmail /kernel: vinum: unloaded > Nov 1 17:51:57 backmail /kernel: vinum: loaded > Nov 1 17:52:05 backmail /kernel: vinum: reading configuration from /dev/da1h > Nov 1 17:52:06 backmail /kernel: vinum: scsivol.p0.s0 is crashed > Nov 1 17:52:06 backmail /kernel: vinum: scsivol.p0 is faulty > Nov 1 17:52:06 backmail /kernel: vinum: scsivol is down > Nov 1 17:52:06 backmail /kernel: vinum: scsivol.p0.s2 is crashed > Nov 1 17:52:06 backmail /kernel: vinum: scsivol.p0 is corrupt > Nov 1 17:52:06 backmail /kernel: vinum: scsivol is up This means that the on-disk config indicates that the subdisks are down. It would have been nice to see the messages when the original problem occurred. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message