From owner-freebsd-stable@FreeBSD.ORG Fri Feb 17 05:46:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13B9B106564A for ; Fri, 17 Feb 2012 05:46:06 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2F538FC16 for ; Fri, 17 Feb 2012 05:46:05 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so2961052vbb.13 for ; Thu, 16 Feb 2012 21:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YgWROjUNcXR0Dv/Xjb8sOWlOyOw65PbmHyrrRSoFKeM=; b=wuT48vSOoiZ583yN99zxqqVb/IVNFA1rEAMi5OjU3XamETMi95QHZlWNyzI5lYoqzz XDvGOmppGOoZ+xTt4KSzNxxfau/lXKo3ZRmCqd38IibSK0QNxIQQulKlSEmh/BpCctmO kYnnJ0xJ21J+bFAnWIIRjly7jXWYvvYUMjIA0= MIME-Version: 1.0 Received: by 10.52.38.10 with SMTP id c10mr2524749vdk.58.1329457564792; Thu, 16 Feb 2012 21:46:04 -0800 (PST) Received: by 10.220.192.135 with HTTP; Thu, 16 Feb 2012 21:46:04 -0800 (PST) In-Reply-To: <20120217.132021.880997830536801810.hrs@allbsd.org> References: <20120217021019.GA61420@icarus.home.lan> <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org> Date: Thu, 16 Feb 2012 21:46:04 -0800 Message-ID: From: Freddie Cash To: Hiroki Sato Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 05:46:06 -0000 On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato wrote: > Jeremy Chadwick wrote > =C2=A0in <20120217030806.GA62601@icarus.home.lan>: > > fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote: > fr> > Sorry, I may be misunderstanding your point. =C2=A0GEOM classes don= 't > fr> > lie, they accurately represent the space. =C2=A0The space provided = by a > fr> > gmirror is one block less than the actual space occupied, to allow > fr> > for the metadata block at the end. =C2=A0The problem is that GPT pu= ts > fr> > backup partition tables at the end of the physical (not logical) > fr> > device. Create a GEOM device on that drive, and the GEOM metadata > fr> > overwrites the backup GPT partition table. =C2=A0Well, the last blo= ck of > fr> > it, anyway. > fr> > > fr> > But create the GEOM device inside a GPT partition that spans the > fr> > drive, and things are fine. =C2=A0The GPT backup tables are safely > fr> > outside the GEOM metadata, which is safely outside of the data. > fr> > fr> I wasn't aware you could do that. =C2=A0I was only aware that it was = the > fr> other way around. =C2=A0That (my) misconception seems to also be rela= yed > fr> by others such as Miroslav who said: > fr> > fr> >>GPT doesn't play nice with GEOM classes which store their metadata > fr> >>on last sector. =C2=A0For example, you can't use gmirror of a whole= drives > fr> >>and use GPT on top of this mirror. (and gmirror is not the only one= ) > fr> > fr> So if I read this correctly, it means that the erroneous behaviour is > fr> the result of someone doing things "in the wrong order" (for lack of > fr> better terminology). > > =C2=A0Well, does GPT really depend on the absolute last block? =C2=A0The = header > =C2=A0has fields for both the first and the last LBAs and they do not hav= e > =C2=A0to be matched with the physical capacity. =C2=A0Creating a gmirror = first, > =C2=A0and then creating a GPT on it does not work? =C2=A0I do not think i= t is > =C2=A0true, and I suspect a description on gmirror recommending > =C2=A0kern.geom.debugflags=3D17 in the handbook is the source of the prob= lem. It's not the partitioning that's the issue. It's the order that GEOM providers and GPT partition tables are "tasted". You can gmirror two disks, then GPT partition the gm0 device without any issues. As you noted, the first/last sectors are 1 less than the physical disk (the size of the gmirror provider). When you boot, though, the gptboot loader only sees the GPT table, it doesn't know that it's part of a gmirror setup. Thus it loads the GPT, notices that the size of the GPT is 1 less sector than the size of the disk, can't find the secondary GPT table as the last sector of the disk is gmirror metadata, and complains about corrupted GPT. Then the kernel loads, gmirror "tastes" the disk, finds the gmirror metadata, configures the gmirror provider, and now all the GPT stuff matches again. And the system carries on correctly. The issue is that we don't have a GEOM-aware loader. Or, at least, that the gpt*boot loaders read the GPT table(s) before configuring the GEOM providers. If we had a gloader that understood all the different GEOM classes, this would be a non-issue. At least, from my limited understanding of things. --=20 Freddie Cash fjwcash@gmail.com