Date: Thu, 06 Oct 2011 14:36:38 +0200 From: Ivan Voras <ivoras@freebsd.org> To: freebsd-current@freebsd.org Cc: freebsd-geom@freebsd.org Subject: Re: RFC: Project geom-events Message-ID: <j6k7cm$mv0$1@dough.gmane.org> In-Reply-To: <4E8D9136.6040200@digsys.bg> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> <4E8C6E85.90005@quip.cz> <CACdU%2Bf8mA1wLUnHVyrJwaf89ahf2oc_904=8mme7kkBLxLSCCQ@mail.gmail.com> <4E8CD662.90202@quip.cz> <j6k252$hpm$1@dough.gmane.org> <4E8D9136.6040200@digsys.bg>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C84C86E817F8180D9458483 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/10/2011 13:29, Daniel Kalchev wrote: >=20 >=20 > 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 labe= l >> 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. >=20 > 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. >=20 > This means that, if you have GPT within GLABEL, for example -- you will= > only see the GPT label if you first see the GLABEL. >=20 > 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. 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. 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. 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. --------------enig3C84C86E817F8180D9458483 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NoNYACgkQldnAQVacBcjcDgCdFad1t6Z4tMNWsNdNvoEHNGxZ CzwAnAs//Jglos0Om0vPjqH30CgW8q5a =Gp69 -----END PGP SIGNATURE----- --------------enig3C84C86E817F8180D9458483--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?j6k7cm$mv0$1>