From owner-freebsd-questions Tue Mar 23 16: 7:58 1999 Delivered-To: freebsd-questions@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 500A714C8A for ; Tue, 23 Mar 1999 16:07:47 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA24632; Wed, 24 Mar 1999 10:37:24 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id KAA00231; Wed, 24 Mar 1999 10:37:18 +1030 (CST) Message-ID: <19990324103717.K425@lemis.com> Date: Wed, 24 Mar 1999 10:37:17 +1030 From: Greg Lehey To: Codeguy , freebsd-questions@FreeBSD.ORG Subject: Re: Beginner questions re. vinum References: <199903232227.OAA19794@wolf.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199903232227.OAA19794@wolf.com>; from Codeguy on Tue, Mar 23, 1999 at 02:27:49PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 23 March 1999 at 14:27:49 -0800, Codeguy wrote: > I'm setting up a new FreeBSD system (3.1) on a Pentium box with two > Quantum Ultra-SCSI drives (4.5 GB each). This box will be used to > log data from two important experiments. Since the data is kind of > important, the powers that be want to have the data mirrored across > the two drives. > > I've currently got 1.2 GB of each drive allocated; swap apace and > root FS on da0, and /work on da1. I'd like to use the remaining 3.3 > GB of each drive for vinum volumes. Any reasons why I shouldn't be > able to do so? None that I can think of. > I *have* read through the man pages (I've got hard copy here in > front of me), and think I have an idea of how to proceed. I've > created a file named /etc/vinum.rc, containing: > > drive drive0 device /dev/da0 > drive drive1 device /dev/da1 > volume www > plex org striped 256k > sd length 1600m drive drive0 > sd length 1600m drive drive1 > volume logs > plex org striped 256k > sd length 1600m drive drive0 > sd length 1600m drive drive1 Looks syntactically correct. > As I understand what I've read, this should identify both hard > drives as eligible for vinum control, identify volumes named "www" > and "logs", each of which is built out of 256 kbyte stripes across > both drives, for a total size of 1600 megs each volume. Is this > more or less correct? Partially. Each volume will have 3200 MB. And they won't be mirrored. To mirror them, you need additional plexes. To judge from what you say above, I think what you want is: drive drive0 device /dev/da0 drive drive1 device /dev/da1 volume www setupstate plex org striped 256k sd length 800m drive drive0 sd length 800m drive drive1 plex org striped 256k sd length 800m drive drive1 sd length 800m drive drive0 volume logs setupstate plex org striped 256k sd length 800m drive drive0 sd length 800m drive drive1 plex org striped 256k sd length 800m drive drive1 sd length 800m drive drive0 This will give you mirrored, striped volumes of 1600 MB. Note that the subdisks of the second plex are stored on the "other" disk relative to the first plex. This means that any write operation to the volume will go to both disks simultaneously. If you didn't do this, the write to the second plex would have to wait for the write to the first plex to complete. > My next step was: > vinum create /etc/vinum.rc > which seemd to complete normally. This was followed by > vinum init www > vinum init logs > which also seemed to complete normally (and very quickly as > well - just a few seconds). I suppose it depends on what you mean by "normally". I rather suspect you got the message www is not a plex logs is not a plex From vinum(8): init plex vinum init initializes a plex by writing zeroes to all its sub- disks. This is the only way to ensure consistent data in a plex. You must perform this initialization before using a RAID-5 plex. It is also recommended for other new plexes. > I then tried > vinum start www > vinum start logs You don't need this unless the objects are down. > which produced after just a few seconds: > vinum: Can't write config top /dev/da0, error 19 > vinum: drive0 is down > vinum: www.p0.s0 is crashed > vinum: www.p0 is corrupt > vinum: logs.p0.s0 is crashed > vinum: logs.p0 is corrupt > vinum: drive1 is down > vinum: www.p0.s1 is crashed > vinum: www.p0 is faulty > vinum: www is down > vinum: logs.p0.s1 is crashed > vinum: logs.p0 is faulty > vinum: logs is down Interesting. I tried this here and got: # vinum start obj Can't start obj: Invalid argument (22) I suppose we could do with a better message than that, but basically it's trying to say "how can I start it when it's already started?". I've changed the code, and now you'll get a message like: # vinum start src.p0.s1 src.p0.s1 is already up I've updated the man page, and soon you will be able to read (under the description of the `start' command): If object names are specified, vinum starts them. Normally this operation is only of use with subdisks. The action depends on the current state of the object: o If the object is already in the up state, vinum does nothing. o If the object is a subdisk in the down or reborn states, vinum changes it to the up state. o If the object is a subdisk in the empty state, the change de- pends on the subdisk. If it is part of a plex which is part of a volume which contains other plexes, vinum places the subdisk in the reviving state and attempts to copy the data from the volume. When the operation completes, the subdisk is set into the up state. If it is part of a plex which is part of a volume which contains no other plexes, or if it is not part of a plex, vinum brings it into the up state immedi- ately. o If the object is a subdisk in the reviving state, vinum con- tinues the revive operation offline. When the operation com- pletes, the subdisk is set into the up state. When a subdisk comes into the up state, vinum automatically checks the state of any plex and volume to which it may belong and changes their state where appropriate. If the object is a volume or a plex, start currently has no ef- fect: it checks the state of the subordinate subdisks (and plexes in the case of a volume) and sets the state of the object accord- ingly. In a later version, this operation will cause the sub- disks > And finally, once I have managed to complete the proper steps > to actually have a working vinum config, what do I need to do > to newfs my vinum volumes? From vinum(4): MAKING FILE SYSTEMS Since vinum volumes do not contain partitions, the names do not need to conform to the standard rules for naming disk partitions. For a physical disk partition, the last letter of the device name specifies the parti- tion identifier (a to h). vinum volumes need not conform to this conven- tion, but if they do not, newfs will complain that it cannot determine the partition. To solve this problem, use the -v flag to newfs. To this I have added: For ex- ample, if you have a volume concat, use the following command to create a ufs file system on it: # newfs -v /dev/vinum/rconcat As with other file systems, you perform the newfs command on the raw de- vice, not the block device. In addition to this, I'll write a section on how to set up vinum in the vinum(8) man page. Real Soon Now. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message