G_PART macro definitions

perryh at pluto.rain.com perryh at pluto.rain.com
Wed Dec 1 09:30:47 UTC 2010


"Andrey V. Elsukov" <bu7cher at yandex.ru> wrote:

> On 30.11.2010 13:35, perryh at pluto.rain.com wrote:
> > 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.
>
> BSD label is located at the beginning of the disk, so when ad0s2a
> is tasted it does detect your current (you call it as "outer") BSD
> label again.

There's _something_ -- probably several things -- about all this that
I am not understanding at all, the most important being:

    How _should_ I be setting this up, so as to
    * mirror only one partition -- not the whole disk or the whole
      FreeBSD slice,
    * subdivide that mirror into journalled root, /var, and /usr
      filesystems, and
    * have the resulting root partition be bootable
    given that the system is too old for its BIOS to recognize GPT?

Some of the rest, in no particular order:

How is the tasting of ad0s2a managing to see the "outer" label -- the
one that defines ad0s2a -- when that label is on ad0s2 prior to the
first block of ad0s2a?  Is tasting permitted to examine parts of the
device outside the boundaries of the provider that is being tasted?

If the problem arises from re-detecting the label (on ad0s2) that
defines ad0s2a, while tasting ad0s2a, how does it work in the normal
case where there is no second label (within ad0s2a)?  Wouldn't the
"outer" (now presumed only) label be redetected in that case also?

If the second label is not being found during the tasting of ad0s2a,
when _is_ it being found?  It certainly seems to be being found at
_some_ point, since we end up with ad0s2a, ad0s2d, and ad0s2e --
the letters corresponding to the second/inner label -- rather than
the ad0s2a and ad0s2b which should be instantiated if only the
first/outer label were being processed; furthermore the ad0s2a,
ad0s2d, and ad0s2e that get instantiated seem to consist of the
block ranges defined by the inner label (else gjournal would not
find its metadata, and the system would not boot and run correctly
once ad0s2a.journal is specified as the root FS and ad0s2[de].journal
are manually mounted as /var and /usr).

Why is ad0s2b never instantiated (even transiently -- I tried
setting kern.geom.debugflags to 1 at the loader prompt, and ad0s2b
was never mentioned at all)?


More information about the freebsd-geom mailing list