Re: RFC: Project geom-events

Ivan Voras wrote:
>> The point was that glabel on disk device is successful, gpartitioning on
>> >  glabeled device is successful, but metadata handling / device tasting is
>> >  wrong after reboot and this should be fixed, not worked around.
>> >
>> >  Otherwise thank you for example with GPT labels, it can be useful in
>> >  some cases.
> 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 only way to get this sorted out is to make a label class (or adapt
> glabel) which does NOT store metadata anywhere on the devices. Maybe
> they can store it in the file system (a file in /etc - though you then
> lose bootability, and have to somehow connect devices and labels), or
> the device hardware ID can be used as a label (but not all devices have
> it, and in case of "software" constructs like iSCSI the labels can be
> changed).

Then there should be warning in documentation or error message printed 
by command in the time of writing metadata.

I am not a GEOM expert, but isn't it wrong concept, that glabel writes 
its metadata and publish original device size? If some GEOM write 
metadata at last sector (or first), then it should shrink the published 
size (or offset). Or is the problem at geom_part, that it is writing 
metadata past the advertised end of the device?

e.g. If I have disk device with size of 100 sectors and glabel metadata 
is stored at the last sector, then glabel should shrink the advertised 
size to 99 sectors - then GPT secondary table will be at sector 99 
instead of 100.

I know there is problem if somebody access the device by its normal 
device node (e.g. /dev/ada0), then secondary GPT table will be at 
different place, not in last sector. But this is the mistake in glabel 
concept and if it cannot be solved by any other way, then glabel should 
not be allowed to place labels on the disk device at all. (if we cannot 
be sure it is non conflicting)

The current state is simply wrong, because user can do something what 
cannot work and is not documented anywhere.

Miroslav Lachman