On 06.10.11 17:04, Pieter de Goeje wrote: > 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. > If you stack GPT on top of glabel, then your statement is not true. GPT will > overwrite the last sector of the (glabel) provider, not the underlying device. > There is no layering violation. I stand corrected. Sorry for creating confusion with this statement. Most of the time I was blaming GPT, I was actually blaming GLABEL (see below) > Because physically the first sector of the device is still GPT data the BIOS > will still try to boot from it, hence it would probably be wise to disallow > GPT on anything other then raw devices. Yes, but.. what is a raw device? Probably disallow GPT on devices that are not bootable, but how this can be indicated? GPT is very useful for it's ability to create labeled partitions. > This problem wouldn't exist if geom classes would write their metadata to the > first sector, but then you could no longer boot from for example > gmirrored/glabeled devices with a MBR. > We seem to blame GPT here, but it is really GLABEL the culprit here. If GLABEL writes to the first sector of the provider and that makes the disk non-bootable, then there is little chance that somebody will try to use first GLABEL, then GPT etc and create the current situation. Unfortunately, the GLABEL + GMIRROR setup is so common..Received on Thu Oct 06 2011 - 12:16:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC