Re: vinum documentation
Greg 'groggy' Lehey wrote: On Saturday, 30 November 2002 at 8:39:44 +, Adam Laurie wrote: Greg 'groggy' Lehey wrote: describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. are you saying that at this point vinum will scan all disk busses and decide for itself that the raid exists, and reconstruct /dev/vinum? Yes. i know you've said in a previous post that /dev/vinum isn't important, but since it contains mount points etc, i assume it's reasonably vital... anyway, our experience when we complete the steps above was that /dev/vinum/raid1 etc. didn't exist, so we couldn't mount the volume, which is why we went on to perform the other steps i described. It looks like you got confused at some point. It's unlikely that you can still reconstruct what happened. yes, i think you are right. however, it is clear to me now why we got confused... since we didn't understand the relationship between vinum and it's devices, we didn't expect it could work until the devices existed, so went down the route of trying to create them before attempting a vinum start... since this unusual relationship isn't explained in the docco, it might be worth adding a paragraph on /dev/vinum and/or a one-liner in the 'start' section to say the devices will be created if they don't exist already... anyway, thatnks for your help in resolving this. it has been most useful. cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 The Storeshttp://www.thebunker.net 2 Bath Road http://www.aldigital.co.uk London W4 1LT mailto:[EMAIL PROTECTED] UNITED KINGDOMPGP key on keyservers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
Adam Laurie wrote: Greg 'groggy' Lehey wrote: describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. are you saying that at this point vinum will scan all disk busses and decide for itself that the raid exists, and reconstruct /dev/vinum? i know you've said in a previous post that /dev/vinum isn't important, but since it contains mount points etc, i assume it's reasonably vital... anyway, our experience when we complete the steps above was that /dev/vinum/raid1 etc. didn't exist, so we couldn't mount the volume, which is why we went on to perform the other steps i described. .. having now digested what youve said so far, and re-read the docco several times, i'm guessing the final step would be: 6. Run 'vinum makedev' in which case our mistake was doing this and 'vinum start' the wrong way around (and then going on to compund the problem in various other ways... :) does this make sense? cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 The Storeshttp://www.thebunker.net 2 Bath Road http://www.aldigital.co.uk London W4 1LT mailto:[EMAIL PROTECTED] UNITED KINGDOMPGP key on keyservers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
Greg 'groggy' Lehey wrote: describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. are you saying that at this point vinum will scan all disk busses and decide for itself that the raid exists, and reconstruct /dev/vinum? i know you've said in a previous post that /dev/vinum isn't important, but since it contains mount points etc, i assume it's reasonably vital... anyway, our experience when we complete the steps above was that /dev/vinum/raid1 etc. didn't exist, so we couldn't mount the volume, which is why we went on to perform the other steps i described. cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 The Storeshttp://www.thebunker.net 2 Bath Road http://www.aldigital.co.uk London W4 1LT mailto:[EMAIL PROTECTED] UNITED KINGDOMPGP key on keyservers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Wed, 4 Dec 2002, Adam Laurie wrote: .. having now digested what youve said so far, and re-read the docco several times, i'm guessing the final step would be: 6. Run 'vinum makedev' in which case our mistake was doing this and 'vinum start' the wrong way around (and then going on to compund the problem in various other ways... :) does this make sense? When I ended up doing/'fixing ours, I just did the vinum start ... tried the vinum makedev before doing the start, and it gave an error, andneverthought about it *after* doing the start ... maybe depends on your OS version? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Wed, Dec 04, 2002 at 02:30:10PM -0400, Marc G. Fournier [EMAIL PROTECTED] wrote: On Wed, 4 Dec 2002, Adam Laurie wrote: .. having now digested what youve said so far, and re-read the docco several times, i'm guessing the final step would be: 6. Run 'vinum makedev' in which case our mistake was doing this and 'vinum start' the wrong way around (and then going on to compund the problem in various other ways... :) does this make sense? When I ended up doing/'fixing ours, I just did the vinum start ... tried the vinum makedev before doing the start, and it gave an error, andneverthought about it *after* doing the start ... Should work with simple 'vinum start'. Configuration is held on disks and swapped around disks shouldn't cause problems. This is by design as I understand. If it weren't.. what a mess, ugh :-) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Saturday, 30 November 2002 at 8:39:44 +, Adam Laurie wrote: Greg 'groggy' Lehey wrote: describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. are you saying that at this point vinum will scan all disk busses and decide for itself that the raid exists, and reconstruct /dev/vinum? Yes. i know you've said in a previous post that /dev/vinum isn't important, but since it contains mount points etc, i assume it's reasonably vital... anyway, our experience when we complete the steps above was that /dev/vinum/raid1 etc. didn't exist, so we couldn't mount the volume, which is why we went on to perform the other steps i described. It looks like you got confused at some point. It's unlikely that you can still reconstruct what happened. 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Wednesday, 4 December 2002 at 9:36:29 +, Adam Laurie wrote: Adam Laurie wrote: Greg 'groggy' Lehey wrote: describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. are you saying that at this point vinum will scan all disk busses and decide for itself that the raid exists, and reconstruct /dev/vinum? i know you've said in a previous post that /dev/vinum isn't important, but since it contains mount points etc, i assume it's reasonably vital... anyway, our experience when we complete the steps above was that /dev/vinum/raid1 etc. didn't exist, so we couldn't mount the volume, which is why we went on to perform the other steps i described. .. having now digested what youve said so far, and re-read the docco several times, i'm guessing the final step would be: 6. Run 'vinum makedev' No. 'vinum start' also creates the devices. in which case our mistake was doing this and 'vinum start' the wrong way around (and then going on to compund the problem in various other ways... :) does this make sense? Well, it's not correct. When you start vinum, it automatically creates the directory if it's not already there: # ls -l /dev/vinum ls: /dev/vinum: No such file or directory # vinum vinum - ^D # ls -l /dev/vinum total 1 crw--- 1 root wheel 91, 0x4001 Dec 5 10:11 Control crw--- 1 root wheel 91, 0x4002 Dec 5 10:11 control crw--- 1 root wheel 91, 0x4000 Dec 5 10:11 controld drwxrwxrwx 2 root wheel 512 Dec 5 10:11 drive drwxrwxrwx 2 root wheel 512 Dec 5 10:11 plex drwxrwxrwx 2 root wheel 512 Dec 5 10:11 sd drwxrwxrwx 2 root wheel 512 Dec 5 10:11 vol Running makedev at this point won't do anything else. 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Wednesday, 4 December 2002 at 14:30:10 -0400, Marc G. Fournier wrote: On Wed, 4 Dec 2002, Adam Laurie wrote: .. having now digested what youve said so far, and re-read the docco several times, i'm guessing the final step would be: 6. Run 'vinum makedev' in which case our mistake was doing this and 'vinum start' the wrong way around (and then going on to compund the problem in various other ways... :) does this make sense? When I ended up doing/'fixing ours, I just did the vinum start ... tried the vinum makedev before doing the start, and it gave an error, Really? What error? andneverthought about it *after* doing the start ... maybe depends on your OS version? No, you almost never need makedev. I can't think of any use for it. 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Thu, 5 Dec 2002, Greg 'groggy' Lehey wrote: When I ended up doing/'fixing ours, I just did the vinum start ... tried the vinum makedev before doing the start, and it gave an error, Really? What error? Don't recall, actually ... I may be mis-remembering though ... all I know is that when I finally took a chance and ran 'vinum start', I didn't do the makedev afterwards and all worked as hoped/expected ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Friday, 29 November 2002 at 10:36:22 +, Adam Laurie wrote: Greg 'groggy' Lehey wrote: On Thursday, 28 November 2002 at 10:06:24 +, Adam Laurie wrote: ok, i'm obviously not making myself clear... my problem wasn't replacing a drive in the RAID, it was replacing the root disk. the system booted off a seperate stand alone root disk. the RAID is entirely independant of the root/boot drive. Yes, you're certainly not making yourself clear. Why did you need to do anything? In a previous message you stated that you did a 'vinum create', though it's not clear why. I suggest you send me (in private mail) the information I ask for in the man page. ok, let's start again... here is a different but functionally equivelant scenario: imagine you two machines, A B: machine A boots off IDE, and has a SCSI card with an external chassis with 10 drives in it. machine B boots off IDE, and has a SCSI card but nothing plugged into it. machine A is configured to have a vinum RAID using only disks on the SCSI card, as per my previous emailed config. machine B is a fresh install, with no vinum configuration. describe the procedure for unplugging the external chassis from machine A, and plugging it into machine B, and bringing up the vinum RAID without re-initialising it (i.e. preserving the data already on it). 1. On machine A, stop Vinum. Depending on the hardware, you may need to shut down. 2. Remove the chassis from machine A. 3. Connect the chassis to machine B. Depending on the hardware, you may need to shut down. 4. If you haven't rebooted machine B, run camcontrol rescan on the SCSI bus to discover the new disks. 5. Run 'vinum start'. the only data you may take from machine A is the vinum config as per my previous email. As I keep trying to tell you, I don't need that. But obviously I can take other data, the Vinum disks themselves. 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
Greg 'groggy' Lehey wrote: 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. ok, i'm obviously not making myself clear... my problem wasn't replacing a drive in the RAID, it was replacing the root disk. the system booted off a seperate stand alone root disk. the RAID is entirely independant of the root/boot drive. cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 The Storeshttp://www.thebunker.net 2 Bath Road http://www.aldigital.co.uk London W4 1LT mailto:[EMAIL PROTECTED] UNITED KINGDOMPGP key on keyservers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Thursday, 28 November 2002 at 10:06:24 +, Adam Laurie wrote: Greg 'groggy' Lehey wrote: 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. ok, i'm obviously not making myself clear... my problem wasn't replacing a drive in the RAID, it was replacing the root disk. the system booted off a seperate stand alone root disk. the RAID is entirely independant of the root/boot drive. Yes, you're certainly not making yourself clear. Why did you need to do anything? In a previous message you stated that you did a 'vinum create', though it's not clear why. I suggest you send me (in private mail) the information I ask for in the man page. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
Greg 'groggy' Lehey wrote: On Monday, 25 November 2002 at 15:42:37 +, 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. 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. please respond to me direct - i am not subscribed to questions... 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 however, when we did a vinum start, raid1.p0.s0 and raid2.p0.s0 went to 'init' state, so we shut it down. the eventual fix was to do a 'vinum read' on each of the devices, set raid1.p0.s0 and raid2.p0.s0 to obsolete (as they had been clobbered by the init) 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? 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). cheers, Adam -- Adam Laurie Tel: +44 (20) 8742 0755 A.L. Digital Ltd. Fax: +44 (20) 8742 5995 The Storeshttp://www.thebunker.net 2 Bath Road http://www.aldigital.co.uk London W4 1LT mailto:[EMAIL PROTECTED] UNITED KINGDOMPGP key on keyservers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Tuesday, 26 November 2002 at 10:58:15 +, Adam Laurie wrote: Greg 'groggy' Lehey wrote: On Monday, 25 November 2002 at 15:42:37 +, 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: vinum documentation
On Monday, 25 November 2002 at 15:42:37 +, 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. the tricky bit was to get vinum to come back up without initialising wiping the volume(s). vinum start please respond to me direct - i am not subscribed to questions... I'd be very interested to know what happened and what you did. Have you read http://www.vinumvm.org/vinum/replacing-drive.html? 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 [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
