RFC: Project geom-events
Pieter de Goeje
pieter at degoeje.nl
Thu Oct 6 14:32:43 UTC 2011
On Thursday, October 06, 2011 02:43:03 PM Daniel Kalchev wrote:
> On 06.10.11 15:36, Ivan Voras wrote:
> > On 06/10/2011 13:29, Daniel Kalchev wrote:
> >> On 06.10.11 14:07, Ivan Voras wrote:
> >>> Um, you do realize this is a "physical" problem with metadata location
> >>> and cannot be solved in any meaningful way? Geom_label stores its label
> >>> in the last sector of the device, and GPT stores the "secondary" /
> >>> backup table also at the end of the device. The two can NEVER work
> >>> together. The same goes for any other GEOM class which stores metadata
> >>> and GPT.
> >> The proper way for this is to have these things store their metadata in
> >> the first/last sector of the provider, not the underlying device.
> >> This means that, if you have GPT within GLABEL, for example -- you will
> >> only see the GPT label if you first see the GLABEL.
> >> I guess the present situation was created out of laziness ;)
> > No, I don't think you understand.
> > The layering *is* correct and you *can* create a GPT inside a glabel
> > label, but then
> > 1) you get device names like /dev/label/somethingp1,
> > /dev/label/somethingp2, etc.
> .. and, you overwrite the last sector of the device, not of the
> provider. This is incorrect layering -- GPT should see only the provider
> it was given and nothing at different layers.
If you stack GPT on top of glabel, then your statement is not true. GPT will
overwrite the last sector of the (glabel) provider, not the underlying device.
There is no layering violation.
So you get this physical layout: Primary GPT header,data,Secondary GPT
Because physically the first sector of the device is still GPT data the BIOS
will still try to boot from it, hence it would probably be wise to disallow
GPT on anything other then raw devices.
This problem wouldn't exist if geom classes would write their metadata to the
first sector, but then you could no longer boot from for example
gmirrored/glabeled devices with a MBR.
More information about the freebsd-current