From owner-freebsd-stable@FreeBSD.ORG Tue May 3 18:34:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 490D116A4CE for ; Tue, 3 May 2005 18:34:05 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD8343D76 for ; Tue, 3 May 2005 18:34:04 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id EEE94215D; Tue, 3 May 2005 11:33:22 -0700 (PDT) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 9A1472151; Tue, 3 May 2005 11:33:22 -0700 (PDT) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j43IY8qm006755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2005 11:34:09 -0700 (PDT) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j43IY7h2006751; Tue, 3 May 2005 11:34:07 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17015.50206.651588.618737@satchel.alerce.com> Date: Tue, 3 May 2005 11:34:06 -0700 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: "stable@freebsd.org" Subject: Re: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 18:34:05 -0000 Eirik =D8verby writes: > Hi! >=20 > I've been using gmirror for a while to safeguard my system disks. I = have > taken the slice-based mirror approach, where I use, say, ad0s1 and a= d2s1 as > providers. > On one of my servers, this seems to be impossible. I create the mirr= or using > ad2s1 first (to keep my system running while I do some of the work),= and > then I re-initialize ad0s1 (making it exactly the size of ad2s1) bef= ore > using gmirror insert to add it to the mirror. > However, at this point - when doing a gmirror list - it turns out th= at it > never added ad0s1 as a provider, but ad0 itself! As a result, I now = have a > load of slices (ad0a, ad0b, ad0d, ad0e, ad0f) instead of having the = same > structure as I have on ad2s1. It's just like ad2s1, just without the= "s1" > part. >=20 > I've tried "dd if=3D/dev/zero of=3D/dev/ad0 bs=3D65536" a couple of = times, in case > some old provider metadata was stored there. I also have exactly the= same > setup in another server, the only difference being that it behaves a= s > expected.. >=20 > Am I doing something blatantly wrong here? This IS supposed to work,= right? > I've even found a very nice description of how to do it at > http://people.freebsd.org/~rse/mirror/ > confirming that what I'm doing is right. >=20 > I'm on 5.4-PRERELEASE, but this problem has been there since 5.3-p2 = or > something, which was when I first tried this. I bet you're getting bitten by a problem that bit me. It's described in the fine print in http://people.freebsd.org/~rse/mirror/. Gmirror saves it's metadata on the last sector of its disk space. Since the slice (adXs1) and the disk device (adX) end at the same place on the disk, gmirror gets confused. It tastes devices in a particular order, apparently devices first, then slices. It finds the metadata when it tastes adX and goes ahead and uses it, even though it should be associating it w/ adXsY. Hilarity ensues.... The fix is described in the fourth comment block of Ralf's doc, either make the slice a sector smaller than the disk device or hardcode the provider name. I've been using the hardcoding approach, and it seems to work for me. g.