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.
_______________________________________________
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"
