Date: Tue, 08 Oct 2013 19:27:23 -0400 From: Michael Powell <nightrecon@hotmail.com> To: freebsd-questions@freebsd.org Subject: Re: failed to create gmirror with the handbook instructions Message-ID: <l324cj$d4n$1@ger.gmane.org> References: <CANuHMWNBToJsPiXzGpJuv77z50aYkdiNnNJy_oz3kMwtqx23eQ@mail.gmail.com> <alpine.BSF.2.00.1310071825200.94688@wonkity.com> <CANuHMWMtMcj_ShgcvzmPyJOAH_gLoSp=mh4Q=ABYtx3VFtA3zw@mail.gmail.com> <alpine.BSF.2.00.1310081551090.29745@wonkity.com> <CANuHMWPNWXLnGH-7F1XdqgxDMJ076bK9Ztr_Rh%2B7p0Nd-AOqTA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l324cj$d4n$1>