From owner-freebsd-geom@FreeBSD.ORG Sat Feb 5 23:04:17 2005 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 876E216A4CE for ; Sat, 5 Feb 2005 23:04:17 +0000 (GMT) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D656943D2D for ; Sat, 5 Feb 2005 23:04:16 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.1/8.13.1) with SMTP id j15N4FEW012648 for ; Sat, 5 Feb 2005 17:04:16 -0600 (CST) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys; Sat Feb 5 17:04:16 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.1/8.13.1/Submit) id j15N4FfT012646; Sat, 5 Feb 2005 17:04:15 -0600 (CST) (envelope-from karl) Message-ID: <20050205170415.A12620@denninger.net> Date: Sat, 5 Feb 2005 17:04:15 -0600 From: Karl Denninger To: Pawel Jakub Dawidek References: <20050205135705.A10437@denninger.net> <20050205201237.GB1666@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20050205201237.GB1666@darkness.comp.waw.pl>; from Pawel Jakub Dawidek on Sat, Feb 05, 2005 at 09:12:37PM +0100 Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! cc: freebsd-geom@FreeBSD.org Subject: Re: Gmirror - how to do? 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: Sat, 05 Feb 2005 23:04:17 -0000 On Sat, Feb 05, 2005 at 09:12:37PM +0100, Pawel Jakub Dawidek wrote: > On Sat, Feb 05, 2005 at 01:57:05PM -0600, Karl Denninger wrote: > +> Howdy; > +> > +> Another quickie someone may know how to handle. > +> > +> I've got a 2-drive RAID1 mirror I wish to back up. > +> > +> The easy way appears to be to attach a third drive, let it sync, detach it > +> and then you have a backup, right? > +> > +> So I do the following: > +> > +> atacontrol attach 2 (attach new disk on external adapter) > +> gmirror insert boot ad4s1 (insert the backup into the existing mirror) > +> wait (while the disk synchronizes - 3-4 hours) > +> gmirror remove boot ad4s1 (remove third copy from mirror) > +> atacontrol detach 2 (remove device from the system) > +> > +> Now I can go pull the carrier "cleanly". > +> > +> Except for one small problem - when you do this, then try to boot the > +> backup volume it fails, because gmirror has marked the metadata as "do > +> not use" when you removed it, yet the /etc/fstab entries all point to a > +> mirror that isn't there. > +> > +> So... how do you accomplish this? > +> > +> Detach the BUS underlying the drive without warning gmirror first (e.g. > +> "atacontrol detach 2", without the preceding "gmirror remove"), thereby > +> forcing a "dirty" disconnect? I'd rather not, although if I must, that I > +> suppose would work. However, if I do this, then gmirror thinks I have a > +> third volume present, and as a consequence as soon I re-init that channel > +> and geom sees the disk it will immediately begin a rebuild (whether this is > +> bad or not I suppose is a matter of interpretation) > > In you case I suggest do this: > > 1. atacontrol attach 2 > 2. gmirror insert boot ad4s1 > > 3. gmirror remove boot ad4s1 > 4. gmirror label boot ad4s1 > 5. atacontrol detach 2 > > In 4th step, you labeling only one provider with the same name. > It will be tasted, but ignored, because mirror 'boot' is already > configured: > > GEOM_MIRROR: Device boot already configured. > > Now it should be bootable. > > Remember not to boot the main machine with this disk inside, as it can > be tasted before your main 'boot' mirror. Inserting this disk after > boot, when your 'boot' mirror is configured should be safe. Nope, won't work. The mirrors potentially have different PHYSICAL slice sizes (remember this debate a while back on this list?) and if I do this, I'm guaranteed to screw the partition table, as the fdisk size of the slice table will be picked up. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.com Musings Of A Sentient Mind