G_PART macro definitions

[perryh at pluto.rain.com]

Marcel Moolenaar <xcllnt at mac.com> wrote:

> > I'm trying to figure out why my disk partitions are not being
> > recognized correctly.  There's a description of what I currently
> > think is happening at
> > http://lists.freebsd.org/pipermail/freebsd-questions/2010-November/224466.html
>
> You're nesting BSD disklabels, which is pretty much an
> invalid configuration. gpart does not support and/or
> allow it.

Granted the BSD disklabels end up looking nested on the disk, but
that's an artifact and not how I intend for it to work.  In fact,
I would expect to have a problem only if gpart _did_ attempt to
support nested BSD disklabels.

The "inner" label is supposed to be on a gmirror, whose (for now
only) provider is a partition defined by the "outer" label, like
this:

ad0 [contains MBR defining s1 (FAT32) and s2 (FreeBSD)]
  ad0s1
  ad0s2 [contains a BSD label defining a and b]
    ad0s2a [provider for gm0]
      gm0 [contains a BSD label defining a, d, and e]
        gm0a [provider for gjournal]
          gm0a.journal [to be used as root]
        gm0d [provider for gjournal]
          gm0d.journal [to be used as /var]
        gm0e [provider for gjournal]
          gm0e.journal [to be used as /usr]
    ad0s2b [to be used as swap]

I think I saw something in the docs to the effect that gm0 is,
effectively, a disk -- so it should be legitimate to partition it
with a BSD label.  I suppose I could use a GPT label instead, but
would the loader still find the kernel on gm0a in that case?
(The system is old enough that its BIOS almost certainly does not
recognize GPT.)  Is there a better way to do this, while still
mirroring only ad0s2a -- not the whole disk or the whole FreeBSD
slice?

How I expect the above scheme to work:

1 ad0 is offered for tasting.  Gpart.mbr finds the MBR and
  instantiates ad0s1 and ad0s2; no race condition arises
  because nothing else likes ad0.

2 ad0s1 is offered for tasting.  Nothing relevant to gpart, gmirror,
  or gjournal likes it.

3 ad0s2 is offered for tasting.  Gpart.bsd finds the (outer) BSD
  label and instantiates ad0s1a and ad0s2a; no race condition arises
  because nothing else likes ad0s2.  (Gpart.bsd _should_ stop as
  soon as it finds the outer label, thus not seeing the inner one.)

4 ad0s2a is offered for tasting.  Gpart.bsd doesn't like it because
  it appears to contain a nested BSD label**.  Gmirror finds its
  metadata at the end of ad0s2a and instantiates gm0.

5 ad0s2b is offered for tasting.  Nothing relevant to gpart, gmirror,
  or gjournal likes it.

6 gm0 is offered for tasting.  Gpart.bsd finds the (inner) BSD label
  and instantiates gm0a, gm0d, and gm0e.

7 gm0a, gm0d, and gm0e are each offered for tasting in turn.
  Gjournal finds its metadata at the end of each, and instantiates
  gm0a.journal, gm0d.journal, and gm0e.journal.

8 (for completeness) gm0a.journal, gm0d.journal, and gm0e.journal are
  each offered for tasting in turn, but nothing in geom likes them;
  they remain available to be mounted as filesystems via /etc/fstab.

It looks as if the problem arises in step 3, when gpart.bsd somehow
processes the inner BSD label instead of the outer one.

__________

** This is where things would go awry if gpart supported nested BSD
   disklabels:  there would be a race between gpart.bsd trying to
   instantiate ad0s2aa, ad0s2ad, and ad0s2ae according to the inner
   label, and gmirror trying to instantiate gm0 according to the
   metadata at the end of ad0s2a.