From owner-freebsd-geom@FreeBSD.ORG Fri Sep 24 16:55:49 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE8116A4CE for ; Fri, 24 Sep 2004 16:55:49 +0000 (GMT) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F18A43D39 for ; Fri, 24 Sep 2004 16:55:49 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from hawkwind.Chelsea-Ct.Org (pool-151-199-91-61.roa.east.verizon.net [151.199.91.61]) by gromit.dlib.vt.edu (8.13.1/8.13.1) with ESMTP id i8OGtk4E015215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2004 12:55:48 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from [192.168.1.25] (zappa [192.168.1.25])i8OGteTt021903; Fri, 24 Sep 2004 12:55:40 -0400 (EDT) From: Paul Mather To: Chris Elsworth In-Reply-To: <20040924160620.GA77997@shagged.org> References: <20040924160620.GA77997@shagged.org> Content-Type: text/plain Message-Id: <1096044939.9306.54.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 24 Sep 2004 12:55:40 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-geom@freebsd.org Subject: Re: WARNING: Expected rawoffset 0, found 63 ? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2004 16:55:49 -0000 On Fri, 2004-09-24 at 12:06, Chris Elsworth wrote: > I feel I'm missing something blatantly obvious here. Is that offset of > 63 something to do with metadata? Have I not left any space for > metadata that I should have done? I was hoping that I'd be able to end > up applying this gmirror command to an existing disk with live data on > it, and then attach a free disk to achieve a complete mirror from an > existing system? Intuitively, I'd say it was more logical to create the mirror first on the slice and *then* label/partition and newfs that. In other words, attach the free disk and create the mirror on that (copying across data from the existing system). Then, when you have the mirror running, add the old drive to it for a two-disk mirror. I recently set up a geom_mirror on a 5.3-BETA5 system, so I thought I'd chip in with my experience. In my case, I was doing a fresh install onto a two-disk system. I did a regular minimal install onto disk 1. Then, I created slices on disk 2 (I wanted one slice for a geom_mirror, another slice for a geom_stripe). Next, I used glabel to label the slice on disk 2 I'd be using for my mirror. (I want to be able to have the disks move ATA ids and not worry about breaking the mirror.) I then created a geom_mirror using gmirror using the labelled provider as the sole provider (and using "-h" to hard-code the providers into the metadata). Now I had my mirror. Then, it was a matter of bsdlabelling the mirror. In my case, I used the same size partitions as my original install on disk 1, but there's no reason why you couldn't resize them. Then, I newfs'd each partition on the mirror and dump/restored the content over from disk 1. Finally, I edited the fstab on the mirror to use /dev/mirror/... for the filesystem mount points, and made sure I was loading geom_label and geom_mirror in its loader.conf. I rebooted using the mirror for a root file system. It was then a simple matter to erase (using dd) the content of the slice that had my initial installation on disk 1 (now inactive) and then label that slice using glabel. Finally, I inserted that labelled slice on disk 1 as a provider to the mirror and automagically geom_mirror began synchronising, copying data from drive 2 onto it. I only ran into three real problems (the first of which was my fault): 1) Initially, I forgot to put a boot block onto drive 2 (the one containing the mirror), and so ran into problems when I erased the drive 1 slice and added it to the mirror, because I'd unwittingly erased my only boot block. (I got around this by booting from the 5.3-BETA5 install CD.:) I'm a bit confused about the "correct way" to render a mirror bootable. (Do you "bsdlabel ... -B ..." the mirror or the underlying providers? I had the same problem with RAIDframe on my NetBSD/alpha. It seems intuitively for a RAID 1 you should be able to installboot onto /dev/raidXc and have the boot blocks transparently written to all the component drives, but you can't. You have to installboot onto the underlying component devices individually.) In the end, I used "fdisk -B" on both underlying drives, and this seemed to work. 2) Sysinstall no longer worked after I created the mirror. This made it inconvenience to do some post-installation tasks that sysinstall makes easy. So, if doing a fresh install, you might want to do those before making your installation into a mirrored one. 3) I was bitten by the lack of a "swapoff -a" in /etc/rc.d/swap1 on 5.3-BETA5. So, I would get a drive synchronising after every reboot. Hopefully the fix in -CURRENT (that I applied by hand) will be MT5 before 5.3-RELEASE. Having done both, I really prefer the easier setup of an all-geom_mirrored system from scratch than a root-on-gvinum setup (at least when using the _Complete FreeBSD_ technique of fiddling with the label and offsets). Geom_mirror seems much easier and cleaner to do; easier, I suspect, largely because you can start initially with just one provider in the mirror and then very easily add another when the original install drive becomes free. You also have much less of a learning curve than with Vinum. (I'm not knocking Vinum here. I use it and like it, but for those people who just want a basic RAID 1 setup on two drives, geom_mirror is the better [simpler] choice, IMHO.) Kudos to Pawel for such a useful GEOM class! Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa