Date: Thu, 16 Feb 2012 21:46:04 -0800 From: Freddie Cash <fjwcash@gmail.com> To: Hiroki Sato <hrs@freebsd.org> Cc: wblock@wonkity.com, mandrews@bit0.com, freebsd-stable@freebsd.org, 000.fbsd@quip.cz, freebsd@jdc.parodius.com Subject: Re: New BSD Installer Message-ID: <CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ@mail.gmail.com> In-Reply-To: <20120217.132021.880997830536801810.hrs@allbsd.org> References: <20120217021019.GA61420@icarus.home.lan> <alpine.BSF.2.00.1202161915520.48218@wonkity.com> <20120217030806.GA62601@icarus.home.lan> <20120217.132021.880997830536801810.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <hrs@freebsd.org> wrote: > Jeremy Chadwick <freebsd@jdc.parodius.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOjFWZ5EhGFr_Vp0%2BTRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ>