Date: Wed, 27 Nov 2002 09:50:50 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Adam Laurie <adam@algroup.co.uk> Cc: questions@freebsd.org Subject: Re: vinum documentation Message-ID: <20021126232050.GB21404@wantadilla.lemis.com> In-Reply-To: <3DE353C7.5080704@algroup.co.uk> References: <3DE244ED.8000903@algroup.co.uk> <20021125224557.GJ41068@wantadilla.lemis.com> <3DE353C7.5080704@algroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, 26 November 2002 at 10:58:15 +0000, Adam Laurie wrote: > Greg 'groggy' Lehey wrote: >> On Monday, 25 November 2002 at 15:42:37 +0000, Adam Laurie wrote: >> >>> hi, >>> >>> who is the best person to talk to regarding vinum docco? >> >> >> I suppose I'm as good as any. >> >> >>> the reason i ask is because i recently had to recover a crashed >>> system with vinum runinng on it, and i had a recovery scenario which >>> doesn't appear to be covered by any of the docs or online faqs... my >>> company has therefore tasked me with submitting a patch and getting >>> said docco updated... >>> >>> fyi, the scenario was that the root disk containing /dev/vinum >>> lost so the whole thing was moved onto a fresh install. >> >> >> That doesn't make any sense. > > sorry - that should have said the root disk *was* lost. i.e. i was > working on a brand new system disk which didn't have /dev/vinum on > it. /dev/vinum isn't important. >>> the tricky bit was to get vinum to come back up without initialising >>> & wiping the volume(s). >> >> vinum start > > see above. since the system didn't know about the raid, there was > nothing to start. You mean there was no other Vinum disk on the system? >> I'd be very interested to know what happened and what you did. > > ok, so we built a new bsd boot disk and did a vinum create with the > original config to create the /dev/vinum tree: > > drive d0 device /dev/da0s1e > drive d1 device /dev/da1s1e > drive d2 device /dev/da2s1e > drive d3 device /dev/da3s1e > drive d4 device /dev/da4s1e > drive d5 device /dev/da5s1e > drive d6 device /dev/da6s1e > drive d7 device /dev/da7s1e > drive d8 device /dev/da8s1e > drive d9 device /dev/da9s1e > volume raid1 > plex org raid5 512k > sd length 5g drive d0 > sd length 5g drive d1 > sd length 5g drive d2 > sd length 5g drive d3 > sd length 5g drive d4 > sd length 5g drive d5 > sd length 5g drive d6 > sd length 5g drive d7 > sd length 5g drive d8 > sd length 5g drive d9 > volume raid2 > plex org raid5 512k > sd length 0 drive d0 > sd length 0 drive d1 > sd length 0 drive d2 > sd length 0 drive d3 > sd length 0 drive d4 > sd length 0 drive d5 > sd length 0 drive d6 > sd length 0 drive d7 > sd length 0 drive d8 > sd length 0 drive d9 This doesn't look like there was no other Vinum disk on the system. > however, when we did a vinum start, raid1.p0.s0 and raid2.p0.s0 went > to 'init' state, so we shut it down. Yes, given that you didn't have a drive d0, that's reasonable. > the eventual fix was to do a 'vinum read' on each of the devices, That wasn't necessary. > set raid1.p0.s0 and raid2.p0.s0 to obsolete (as they had been > clobbered by the init) Well, it seems they didn't exist. > and then start everything. > > i suspect what i should have done right from the start was just the > 'vinum read' on each hard disk instead of the create which made it think > it was a new raid? You don't need vinum read. It already knew about the disks. >> Have you read http://www.vinumvm.org/vinum/replacing-drive.html? > > yep. like all the others i've found, this deals with fixing problems > within the raid itself, not moving a working raid onto a new system > (which is effectively what i was doing). No, it addresses exactly your problem, modulo the fact that your plexes were RAID-5. I'd be interested in what makes you think it's different. 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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021126232050.GB21404>