From owner-freebsd-geom@FreeBSD.ORG Fri Sep 24 19:19:45 2004 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 5E6E316A4CE for ; Fri, 24 Sep 2004 19:19:45 +0000 (GMT) Received: from clueful.shagged.org (clueful.shagged.org [212.13.201.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E04643D53 for ; Fri, 24 Sep 2004 19:19:45 +0000 (GMT) (envelope-from chris@clueful.shagged.org) Received: from chris by clueful.shagged.org with local (Exim 4.40 (FreeBSD)) id 1CAvbW-000MLa-U8; Fri, 24 Sep 2004 20:19:38 +0100 Date: Fri, 24 Sep 2004 20:19:38 +0100 From: Chris Elsworth To: Paul Mather Message-ID: <20040924191938.GA84500@shagged.org> References: <20040924160620.GA77997@shagged.org> <1096044939.9306.54.camel@zappa.Chelsea-Ct.Org> <20040924171810.GA80912@shagged.org> <1096050986.9306.72.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1096050986.9306.72.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.5.6i Sender: Chris Elsworth X-Shagged-MailScanner-Information: See www.mailscanner.info for information X-Shagged-MailScanner: Found to be clean X-MailScanner-From: chris@clueful.shagged.org cc: freebsd-geom@freebsd.org Subject: Re: WARNING: Expected rawoffset 0, found 63 ? 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: Fri, 24 Sep 2004 19:19:45 -0000 On Fri, Sep 24, 2004 at 02:36:27PM -0400, Paul Mather wrote: > On Fri, 2004-09-24 at 13:18, Chris Elsworth wrote: > > > At this point, or indeed, even now, if you disklabel -r on your mirror > > device, does it not give you warnings about partition c? If not, > > that's where we start to differ :) > > First of all, you should probably get into the habit of using bsdlabel > under 5.x, not disklabel. (I remember at one point that disklabel used > to complain about that rawoffset difference.) Perhaps they are exactly > the same nowadays, but at one point they weren't. They seem to be exactly the same at the moment (same inode) although that might not be true forever, so noted, thanks :) > Here's what I get when I run disklabel on my mirror: > > >>>>> > zappa# disklabel -r /dev/mirror/raid1 > # /dev/mirror/raid1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 524288 0 4.2BSD 2048 16384 32776 > b: 2039392 524288 swap > c: 20964760 0 unused 0 0 # "raw" part, don't edit > d: 524288 2563680 4.2BSD 2048 16384 32776 > e: 17876792 3087968 4.2BSD 2048 16384 28552 > <<<<< > > The only time I get a complaint about partition c is when I run it on > the underlying components (providers). Then, it complains about it not > covering the whole device, which makes sense because it is picking up a > "ghost" label of the mirror, which is slightly smaller than the > underlying providers because it uses a few sectors from them for its own > metadata. E.g.: Aha! After reading that a couple of times something clicked - the mirror had the disklabel from the disk *before* the mirror was applied. So I created the mirror, then cleaned the mirror with a dd of zero bytes to the first few sectors, then bsdlabel -w /dev/mirror/gm, and I have the following: app1# bsdlabel -r /dev/da1s1 # /dev/da1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 71119675 16 unused 0 0 c: 71119691 0 unused 0 0 # "raw" part, don't edit bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities app1# bsdlabel -r /dev/mirror/gm # /dev/mirror/gm: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 71119675 16 unused 0 0 c: 71119691 0 unused 0 0 # "raw" part, don't edit So now another two things crop up - where has that a partition come from (perhaps that's just what bsdlabel -w does by default, no big deal) but more importantly, why do they both have an offset of 16 bytes.. It didn't seem to mind me changing it to zero, though. So now I'll see if I can get it booting :) Thanks for the brain stirring, it did the trick :) -- Chris