Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Sep 2004 12:55:40 -0400
From:      Paul Mather <paul@gromit.dlib.vt.edu>
To:        Chris Elsworth <chris@shagged.org>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: WARNING: Expected rawoffset 0, found 63 ?
Message-ID:  <1096044939.9306.54.camel@zappa.Chelsea-Ct.Org>
In-Reply-To: <20040924160620.GA77997@shagged.org>
References:  <20040924160620.GA77997@shagged.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1096044939.9306.54.camel>