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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
