Freddie Cash <fjwc...@gmail.com> wrote in <caojfwz5ehgfr_vp0+trfxvgm6kzxv9qo3ufvdkura96z3ax...@mail.gmail.com>:
fj> On Thu, Feb 16, 2012 at 8:20 PM, Hiroki Sato <h...@freebsd.org> wrote: fj> > Jeremy Chadwick <free...@jdc.parodius.com> wrote fj> > in <20120217030806.ga62...@icarus.home.lan>: fj> > 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> > 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> 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> 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> 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> 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> 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 drvsize() failed. -- Hiroki
pgpTRoiMCJIgR.pgp
Description: PGP signature