Re: RFC: Project geom-events

> I am not a GEOM expert, but isn't it wrong concept, that glabel writes
> its metadata and publish original device size? 

It does not.

# diskinfo -v /dev/md0
/dev/md0
        512             # sectorsize
        104857600       # mediasize in bytes (100M)
        204800          # mediasize in sectors
        0               # stripesize
        0               # stripeoffset

# glabel create /dev/label/blah md0

# diskinfo -v /dev/label/blah
/dev/label/blah
        512             # sectorsize
        104857088       # mediasize in bytes (100M)
        204799          # mediasize in sectors
        0               # stripesize
        0               # stripeoffset

(i.e. one sector is used for glabel).

# gpart create -s GPT /dev/label/blah

# gpart add -t freebsd -l gptpart label/blah

# diskinfo -v /dev/label/blahs1
/dev/label/blahs1
        512             # sectorsize
        104822784       # mediasize in bytes (100M)
        204732          # mediasize in sectors
        0               # stripesize
        17408           # stripeoffset
        710             # Cylinders according to firmware.
        32              # Heads according to firmware.
        9               # Sectors according to firmware.

(i.e. 67 sectors are used for: protective MBR (1), GPT header (1), GPT
table (32), the backup GPT header (1) and the backup GPT table (32)).

> If some GEOM write
> metadata at last sector (or first), then it should shrink the published
> size (or offset). 

It does that.

> Or is the problem at geom_part, that it is writing
> metadata past the advertised end of the device?

There is no "problem" as far as I can see. The only possible problem is
that you are trying to do something outside the specification. This is
not the fault of FreeBSD, GEOM, or glabel, and it's even probably not
the fault of the specification as it cannot avoid real-world problems
such as this.

See this:

http://www.uefi.org/specs/

If the primary GPT is invalid, the backup GPT is used instead and it is
located on the last logical
block on the disk. If the backup GPT is valid it must be used to restore
the primary GPT. If the
primary GPT is valid and the backup GPT is invalid software must restore
the backup GPT. If both
the primary and backup GPTs are corrupted this block device is defined
as not having a valid GUID
Partition Header.

Even though the primary GPT header contains the LBA of the backup GPT
header, this paragraph says that it must be the last sector 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.

Maybe an illustration will help. In the scenario like the above, this is
what you have on the drive:

[ PMBR | GPT 1 | --- random file system data --- | GPT 2 | glabel ]

The $glabeled_size is $device_sectors - 1.
The size of the GPT "available space" is $glabeled_size - 67.

Since the PMBR and primary GPT headers are located at the start of the
drive, they are detected there. A tool which is made to the
specification from the paragraph above will detect that the second GPT
table (GPT 2) is invalid in this configuration and will try to "fix" it
by destroying the glabel metadata.

It doesn't matter that from GEOM's point of view, the layering is
correct and the provider sizes are calculated correctly. If you want to
do this, you must do it with something which isn't GPT.