Date: Thu, 06 Oct 2011 13:07:13 +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: <j6k252$hpm$1@dough.gmane.org> In-Reply-To: <4E8CD662.90202@quip.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig63264E9C8E2E26DC9D0B4E34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/10/2011 00:12, Miroslav Lachman wrote: > Scot Hetzel wrote: >> 2011/10/5 Miroslav Lachman<000.fbsd@quip.cz>: >>> I am waiting years for the moment, when these GEOM problems will be >>> fixed, >>> so I am really glad to see your interest! >>> It will be move to right direction even if changes will not be backwa= rd >>> compatible. >>> The current state is too fragile to be used in production. Gmirror >>> alone can >>> be used, glabel alone can be used, GPT alone can be used... but mix >>> it all >>> stacked together is way to hell. >>> >>> e.g. Using GPT on glabeled provider always ends with error message ab= out >>> corrupted secondary GPT table. (But how can I use iSCSI in reliable >>> way if I >>> cannot use glable on devices and iSCSI device can have different >>> number on >>> each reboot? I wrote about it almost 2 years ago) >>> >> You don't need to use glabel on GPT disks, as gpart has it's own way >> to label GPT disks: >=20 > [...] >=20 > The point was that glabel on disk device is successful, gpartitioning o= n > glabeled device is successful, but metadata handling / device tasting i= s > wrong after reboot and this should be fixed, not worked around. >=20 > 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). --------------enig63264E9C8E2E26DC9D0B4E34 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/ iEYEARECAAYFAk6Ni+EACgkQldnAQVacBcigLQCg2PZe7L8bQqSwzqzSNo+HZG6l 3gUAoI0LsvVC8UWQc3SuROGfkilp50i5 =KF0d -----END PGP SIGNATURE----- --------------enig63264E9C8E2E26DC9D0B4E34--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?j6k252$hpm$1>