RFC: Project geom-events

Daniel Kalchev daniel at digsys.bg
Thu Oct 6 14:16:12 UTC 2011



On 06.10.11 17:04, Pieter de Goeje wrote:
> 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.

I stand corrected. Sorry for creating confusion with this statement.

Most of the time I was blaming GPT, I was actually blaming GLABEL (see 
below)

> 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.
Yes, but.. what is a raw device? Probably disallow GPT on devices that 
are not bootable, but how this can be indicated? GPT is very useful for 
it's ability to create labeled partitions.

> 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.
>
We seem to blame GPT here, but it is really GLABEL the culprit here.

If GLABEL writes to the first sector of the provider and that makes the 
disk non-bootable, then there is little chance that somebody will try to 
use first GLABEL, then GPT etc and create the current situation.

Unfortunately, the GLABEL + GMIRROR setup is so common..


More information about the freebsd-current mailing list