RFC: Project geom-events

[Daniel Kalchev]

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.

>
> 2) this makes the device unbootable as the GPT partition is per
> definition not valid. It still stores the primary partition table on the
> first sector (and the following sectors...), but its secondary table is
> stored at one sector short of device's last sector (which is used by
> glabel). Any utilities and BIOSes which test for GPT will find the first
> table but not the last and depending on how sensitive / broken they are,
> they will either recognize a broken GPT (and/or try to fix it,
> destroying the glabel label), or not work at all.

This is why I said, "lazy". If you use proper layering, the GPT within 
another GEOM provider should be unbootable. No BIOS should ever "see" 
it. The rationale of using GPT within another GEOM is questionable, but 
apparently has applications.

> You could argue that the GPT design is broken, but it was always, per
> design, only made to work on whole drives. There is no way to use it
> with any other scheme which uses either the first or the last sectors of
> a drive.

I am not arguing this.

But suppose you use GPT on HAST providers. These cannot boot so whether 
GPT is bootable in that case is irelevant.

> Luckily, GPT also provides its own labels (per design) and instead of
> labeling the provider, you could just as easily label the individual
> partitions and skip glabel in this case.
>

That is another option, yes. But this does not mean we do not have a issue.

Probably, it should be simply disallowed to use GPT within GLABEL. Or, 
in cases where this might be beneficial, use sort of 'boot-less' GPT.

Probably, the problem here is with GLABEL, that does not use the first 
sector as well.