RAID1 with gmirror

Christian Hiris 4711 at
Tue Oct 12 09:55:56 PDT 2004

Hash: SHA1

On Monday 11 October 2004 17:56, Paul Mather wrote:
> On Mon, 11 Oct 2004 14:26:06 +0100, Chris Elsworth <chris at>
> wrote:
> > So, I'm left quite unsure whether the warnings are harmless or not.
> > Pawel, can we just use existing labels on disks and apply a gmirror
> > over it, or should we be re-labelling inside the mirror device?
> I believe it is safer to re-bsdlabel the mirror device rather than use
> an existing disklabel.  Remember, the mirror device uses one sector at
> the end of each provider to store its metadata.  So, if you use the
> existing provider's disklabel, you will at the very least get complaints
> concerning the label about the "c" partition extending past the end of
> the device (because the "c" partition will be one sector too long now).

Just an example how to find out, if there is a risk that metadata will 
overwrite userdata on an existing slice:

Our disk is ad6.
Our existing slice is ad6s1, it holds 4 partitions (/ swap /usr /home)
We want to mirror the whole disk. 

# boot -v

ad6: <Maxtor 6Y120P0/YAR41BW0> ATA-7 disk at ata3-master
ad6: 117246MB (240121728 sectors), 238216 C, 16 H, 63 S, 512 B
               ^^^^^^^^^                                 ^^^
** raw size is 240121728 sectors
** sectorsize is 512 bytes.
** last sector 240121728 will hold our new gmirror metadata.

ad6: 16 secs/int, 1 depth queue, UDMA133
[0] f:00 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:240107427
** the 63 sector offset displayed by bsdlabel after gmirror has been started

[1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
[2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
[3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
GEOM: new disk ad6
GEOM: Configure ad6s1, start 32256 length 122935002624 end 122935034879
                             ^^^^^                         ^^^^^^^^^^^^
** slice starts at sector 63 [32256/512] 
** slice ends at sector 240107489 [122935034879/512]

Now we have all information we need:
Raw disksize in sectors     240121728
Slice ad6s1 ends at sector  240107489

So we see that our new metadata, which will be stored in sector 240121728,  
never will touch any userdata inside slice ad6s1.      

Curiously, we want to check what happens in real life:

# gmirror label -b split -s 16384 mirror0 ad6
# gmirror list
Geom name: mirror0
Components: 2
Balance: split
Slice: 16384
Flags: NONE
SyncID: 3
ID: 2363178490
1. Name: mirror/mirror0
   Mediasize: 122942324224 (114G)

** new gmirror device 240121727 sectors [122942324224/512]

   Sectorsize: 512
   Mode: r4w4e2
1. Name: ad6
   Mediasize: 122942324736 (114G)

** raw device 240121728 sectors [122942324736/512]
** sector 24012178 holds our metadata

   Sectorsize: 512
   Mode: r4w4e3
   State: ACTIVE
   Priority: 1
   Flags: DIRTY
   SyncID: 3
   ID: 3530324446

check if metadata really live in sector 240121728:
# dd if=/dev/ad6 of=/root/meta skip=240121727 count=1
# more /root/meta

> Also, if you are unlucky, the mirror metadata might overwrite (and
> render inaccessible) a sector's worth of actual filesystem data in the
> last sector from the original provider when you create the mirror.  That
> could cause problems.
> Labelling the mirror device ensures that filesystem data is not on any
> inaccessible sectors (assuming you don't deliberately create an invalid
> label on the new mirror device:).
> FWIW, I outline in a posting to freebsd-geom the steps I took to do a
> fresh install of FreeBSD 5.3-BETA to create an root-on-gmirror setup
> (
>).  A similar technique could be used to gmirror an existing setup.

Thanks, for the link (Chris already pointed me to this thread). I will try 
this on a testmachine.           

> Cheers,
> Paul.

- -- 
Christian Hiris <4711 at> | OpenPGP KeyID 0x3BCA53BE 
OpenPGP-Key at hkp:// and
Version: GnuPG v1.2.6 (FreeBSD)


More information about the freebsd-current mailing list