Date: Thu, 6 Oct 2011 16:04:14 +0200 From: Pieter de Goeje <pieter@degoeje.nl> To: freebsd-current@freebsd.org Cc: Daniel Kalchev <daniel@digsys.bg> Subject: Re: RFC: Project geom-events Message-ID: <201110061604.15036.pieter@degoeje.nl> In-Reply-To: <4E8DA257.9080406@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <j6k7cm$mv0$1@dough.gmane.org> <4E8DA257.9080406@digsys.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, October 06, 2011 02:43:03 PM Daniel Kalchev wrote: > 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. 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. So you get this physical layout: Primary GPT header,data,Secondary GPT header,glabel metadata. 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. 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. - Pieter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110061604.15036.pieter>