Date: Mon, 9 Dec 2002 10:21:43 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Matt Ruby <mruby2003@yahoo.com> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: vinum question - Is this possible? Message-ID: <20021208235143.GP96646@wantadilla.lemis.com> In-Reply-To: <20021208171753.30498.qmail@web14508.mail.yahoo.com> References: <20021208171753.30498.qmail@web14508.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 8 December 2002 at 9:17:53 -0800, Matt Ruby wrote: > This is my plan: > 1. Set up an empty 40G drive with vinum. > 2. Copy what I need from another 40G drive to it. > 3. Erase the second drive and set it up with vinum, > too, so that I have a mirrored set containing the > original data (or most of it, anyway). > > Is this possible? Yes. > If so, I'm not at all clear about how I should go about it. In a > trial run, I had no problems with setting up the empty drive with > vinum, but then writing a second configuration to the same drive as > an experiment resulted in a non-functioning system. (Further > research confirms this was the wrong thing to do.) > > I originally assumed I could simply follow the instructions for > replacing a failed drive, but after reading them, am puzzled about > how (if it's possible at all) to "create the impression" of there > having been a drive that now needs to be rebuilt. Can anyone offer > some suggestions? In the case of a failed drive, Vinum knows all about it, just not where it is. In your case Vinum doesn't know about the new disk; you have to tell it. Do that with an incremental configuration file just describing the new objects. I'm attaching a draft from the upcoming 4th edition of "The Complete FreeBSD". Take a look at it and tell me if anything's unclear. 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 Adding plexes to an existing volume ___________________________________ At some time after creating a volume, you may decide to add additional plexes. This is only possible for concatenated plexes. For example, you may want to add a plex to the volume myvol we saw above, putting its subdisk on drive b. The configuration file for this extension would look like: plex name myvol.p1 org concat volume myvol sd size 1g drive b To see what has happened, use the recursive listing option -r for the list command: vinum -> l -r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: up Subdisks: 1 Size: 512 MB P myvol.p1 C State: initializing Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p1.s0 State: empty D: b Size: 1024 MB The command l is a synonym for list, and the -r option means recursive: it displays all subordinate objects. In this example, plex myvol.p1 is 1 GB in size, although myvol.p0 is only 512 MB in size. This discrepancy is allowed, though it isn't very useful by itself: only the first half of the volume is protected against failures. As we'll see in the next section, though, this is a useful stepping stone to extending the size of a file system. Note that you can't use the setupstate keyword here. Vinum can't know whether the existing volume contains valid data or not, so you must use the start command to synchronize the plexes. Adding subdisks to existing plexes __________________________________ After adding a second plex to myvol, it had one plex with 512 MB and another with 1024 MB. It makes sense to have the same size plexes, so the first thing we should do is add a second subdisk to the plex myvol.p0. Do this in much the same manner: sd name myvol.p0.s1 plex myvol.p0 size 512m drive c After adding this subdisk, the volume looks like this: | | | | | | 0 MB | myvol.p0.s0 | | | |volume | | |addressvol.p1.s0 | myvol.p0.s1 space | | | | 1024 MB | | | | Plex 1 Plex 2 | | myvol.p0 myvol.p1 | | | Figure 17-7: An extended Vinum volume It doesn't look too happy, however: vinum -> l -r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: corrupt Subdisks: 2 Size: 1024 MB P myvol.p1 C State: initializing Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p0.s1 State: empty D: c Size: 512 MB S myvol.p1.s0 State: stale D: b Size: 1024 MB In fact, it's in as good a shape as it ever has been. The first half of myvol still contains the file system that we put on it, and it's as accessible as ever. The trouble here is that there is nothing in the other two subdisks, which are shown shaded in the figure. Vinum can't know that that is acceptable, but we do. In this case, we use some maintenance commands to set the correct object states: vinum -> setstate up myvol.p0.s1 myvol.p0 vinum -> l -r myvol V myvol State: up Plexes: 2 Size: 1024 MB P myvol.p0 C State: up Subdisks: 2 Size: 1024 MB P myvol.p1 C State: faulty Subdisks: 1 Size: 1024 MB S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p0.s1 State: up D: c Size: 512 MB S myvol.p1.s0 State: stale D: b Size: 1024 MB vinum -> saveconfig The command setstate changes the state of individual objects without updating those of related objects. For example, you can use it to change the state of a plex to up even if all the subdisks are down. If used incorrectly, it can can cause severe data corruption. Unlike normal commands, it doesn't save the configuration changes, so you use saveconfig for that, after you're sure you have the correct states. Read the man page before using them for any other purpose. Next you start the second plex: vinum -> start myvol.p1 Reviving myvol.p1.s0 in the background vinum[446]: reviving myvol.p1.s0 vinum -> vinum[446]: myvol.p1.s0 is up some time later l command for previous prompt 3 drives: D a State: up /dev/da1s4h A: 3582/4094 MB (87%) D b State: up /dev/da2s4h A: 3070/4094 MB (74%) D c State: up /dev/da3s4h A: 3582/4094 MB (87%) 1 volumes: V myvol State: up Plexes: 2 Size: 1024 MB 2 plexes: P myvol.p0 C State: up Subdisks: 2 Size: 1024 MB P myvol.p1 C State: up Subdisks: 1 Size: 1024 MB 3 subdisks: S myvol.p0.s0 State: up D: a Size: 512 MB S myvol.p1.s0 State: up D: b Size: 1024 MB S myvol.p0.s1 State: up D: c Size: 512 MB The message telling you that myvol.p1.s0 is up comes after the prompt, so the next command doesn't have a prompt. At this point you have a fully mirrored, functional volume, 1 GB in size. If you now look at the contents, though, you see: # df /mnt Filesystem 1048576-blocks Used Avail Capacity Mounted on /dev/vinum/myvol 503 1 461 0% /mnt The volume is now 1 GB in size, but the file system on the volume is still only 512 MB. To expand it, use growfs: # umount /mnt # growfs /dev/vinum/myvol We strongly recommend you to make a backup before growing the Filesystem Did you backup your data (Yes/No) ? Yes new file systemsize is: 524288 frags Warning: 261920 sector(s) cannot be allocated. growfs: 896.1MB (1835232 sectors) block size 16384, fragment size 2048 using 7 cylinder groups of 128.02MB, 8193 blks, 16512 inodes. super-block backups (for fsck -b #) at: 1048736, 1310912, 1573088 # mount /dev/vinum/myvol /mnt # df /mnt Filesystem 1048576-blocks Used Avail Capacity Mounted on /dev/vinum/myvol 881 1 809 0% /mnt 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?20021208235143.GP96646>