New BSD Installer
hrs at FreeBSD.org
Fri Feb 17 07:07:05 UTC 2012
Freddie Cash <fjwcash at gmail.com> wrote
in <CAOjFWZ5EhGFr_Vp0+TRfxvgm6KZxv9QO3UfVdKurA96z3axDMQ at mail.gmail.com>:
fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <hrs at freebsd.org> wrote:
fj> > Jeremy Chadwick <freebsd at jdc.parodius.com> wrote
fj> > in <20120217030806.GA62601 at icarus.home.lan>:
fj> > fr> On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:
fj> > fr> > Sorry, I may be misunderstanding your point. GEOM classes don't
fj> > fr> > lie, they accurately represent the space. The space provided by a
fj> > fr> > gmirror is one block less than the actual space occupied, to allow
fj> > fr> > for the metadata block at the end. The problem is that GPT puts
fj> > fr> > backup partition tables at the end of the physical (not logical)
fj> > fr> > device. Create a GEOM device on that drive, and the GEOM metadata
fj> > fr> > overwrites the backup GPT partition table. Well, the last block of
fj> > fr> > it, anyway.
fj> > fr> >
fj> > fr> > But create the GEOM device inside a GPT partition that spans the
fj> > fr> > drive, and things are fine. The GPT backup tables are safely
fj> > fr> > outside the GEOM metadata, which is safely outside of the data.
fj> > fr>
fj> > fr> I wasn't aware you could do that. I was only aware that it was the
fj> > fr> other way around. That (my) misconception seems to also be relayed
fj> > fr> by others such as Miroslav who said:
fj> > fr>
fj> > fr> >>GPT doesn't play nice with GEOM classes which store their metadata
fj> > fr> >>on last sector. For example, you can't use gmirror of a whole drives
fj> > fr> >>and use GPT on top of this mirror. (and gmirror is not the only one)
fj> > fr>
fj> > fr> So if I read this correctly, it means that the erroneous behaviour is
fj> > fr> the result of someone doing things "in the wrong order" (for lack of
fj> > fr> better terminology).
fj> > Well, does GPT really depend on the absolute last block? The header
fj> > has fields for both the first and the last LBAs and they do not have
fj> > to be matched with the physical capacity. Creating a gmirror first,
fj> > and then creating a GPT on it does not work? I do not think it is
fj> > true, and I suspect a description on gmirror recommending
fj> > kern.geom.debugflags=17 in the handbook is the source of the problem.
fj> It's not the partitioning that's the issue. It's the order that GEOM
fj> providers and GPT partition tables are "tasted".
fj> You can gmirror two disks, then GPT partition the gm0 device without
fj> any issues. As you noted, the first/last sectors are 1 less than the
fj> physical disk (the size of the gmirror provider).
fj> When you boot, though, the gptboot loader only sees the GPT table, it
fj> doesn't know that it's part of a gmirror setup. Thus it loads the
fj> GPT, notices that the size of the GPT is 1 less sector than the size
fj> of the disk, can't find the secondary GPT table as the last sector of
fj> the disk is gmirror metadata, and complains about corrupted GPT.
fj> Then the kernel loads, gmirror "tastes" the disk, finds the gmirror
fj> metadata, configures the gmirror provider, and now all the GPT stuff
fj> matches again. And the system carries on correctly.
fj> The issue is that we don't have a GEOM-aware loader. Or, at least,
fj> that the gpt*boot loaders read the GPT table(s) before configuring the
fj> GEOM providers.
No, the issue is our gptloader assumes the backup header is always
located at the (physical) last sector while this is not mandatory in
the UEFI specification. GEOM-based logical volumes suffer from this
assumption at boot time. It is not practical (and not necessary) to
taste the volumes before loading a kernel.
If the primary header is valid, using a lookup order of the
hdr_lba_alt(AlternateLBA), the hdr_lba_end(LastUsableLBA), then
drvsize() - 1 looks reasonable to me. The current code uses
drvsize() - 1 first and then looks up the AlternateLBA only when
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120217/d627bc17/attachment.pgp
More information about the freebsd-stable