Re: RFC: Project geom-events

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.

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.

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.

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.