failed to create gmirror with the handbook instructions

[Michael Powell]

Andy Zammy wrote:

> # gpart show ada0s1
> gpart: No such geom: ada0s1
> 
> By the way, this is after a restart of the machine.
> 
> There's nothing to back up, I'm installing a fresh os, so I just install
> on one drive, plug the other in, and start following the handbook
> instructions for this method. So the only thing in loader.conf is
> geom_mirror_load="YES".
> 
[snip]

Since you are beginning to reinstall from scratch, please allow/forgive a 
small interjection from some of my recent experience with this. Warren is 
more knowledgeable on this than I am, and I have followed many of his 
instructions in the past.

With the shift towards GPT and away from the old DOS mbr/partition table stuff 
of the past, the current Handbook pages reflect this. The central point of 
contention arises from the fact that GPT, GEOM (gmirror), and many hardware 
RAID controllers require to claim the very last sector of a drive to store 
their metadata. Obviously, the effect of this collision is a "whoever wrote 
last wrote best" - so you can't use combinations of things that all want 
this sector.

The most simple gmirroring is to slice an entire drive, with partitions 
contained within. The very end of the drive must NOT have any file system on 
it, and this is usually the case by default as most of the time 
slicing/partitioning leaves a little free space at the end anyway. This will 
not work with GPT; only with the old DOS compatible mbr and disklabel 
scheme.

In order to use GPT and gmirror together you gmirror individual partitions 
(as opposed to the slice) , e.g. gmirror will write its metadata at the end 
of each partition leaving the very last sector at the end of the drive for 
GPT. This is what the content on the relevant Handbook pages reflects.   
More complicated, but allows for the demise of the ancient DOS/mbr 
partitioning.

Notice that if you combine GPT and a hardware RAID controller card the same 
collision problem noted previously can still happen. If you utilize the BIOS 
on the controller card for anything it will save its metadata on the last 
drive sector.

When not faced with terabyte sized humongous volumes and the huge amount of 
time an fsck will consume, the old DOS way with disklabel is still an option 
that works. The main reason for the journaling is to sidestep waiting for a 
very long fsck on a huge volume to run to completion before finishing a boot 
into a cleaned up/repaired file system. If your drive volume is small this 
is not so much a problem. Indeed my old gateway/firewall/IDS router box I 
did the old DOS/mbr scheme with gmirror (the old single-slice entire drive 
and mirror the drive) as the pair of drives are ancient 74GB Raptors.

On my web/database test box I did go the GPT and SUJ+journaling route but am 
not using any mirroring here (yet). I have not experienced any problems with 
dump - but I also do not use the -L switch. It will show an error/warning 
about not dumping a live file system this way but I go ahead and do it 
anyway. IIRC the dump problem you may be seeing may be related to drive 
snapshotting. The caveat is I can sort of 'get away' with it as my boxen are 
largely quiescent, but would hesitate to do this on something like a public 
web/database box that was continually being hammered with lots of traffic.

Just tossing out some ideas for your perusal and consideration. The way I 
used the old DOS/mbr and disklabel scheme on my router machine is very 
simple, quick to do, and has survived a few power outages now with no data 
loss (other than the time it takes to rebuild which it does automagically on 
boot). On the 74GB Raptors this rebuild takes about twenty minutes. Your 
situation and needs may force you in a different direction. Hence, the 
proverbial "YMMV" applies. FWIW. Now for to finally get around to purchasing 
a new UPS to replace the old one that went up in smoke and died horribly...

-Mike