Date: Fri, 29 Jun 2012 01:07:26 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Doug Rabson <dfr@FreeBSD.org>, Marcel Moolenaar <marcel@FreeBSD.org>, Christian Laursen <xi@borderworlds.dk>, freebsd-hackers <freebsd-hackers@FreeBSD.org>, Andriy Gapon <avg@FreeBSD.org>, Stefan Esser <se@FreeBSD.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru>, Alexander Leidinger <Alexander@Leidinger.net>, freebsd-current <freebsd-current@FreeBSD.org> Subject: Re: [CFC/CFT] large changes in the loader(8) code Message-ID: <20120628230725.GB1438@garage.freebsd.pl> In-Reply-To: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> References: <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 28, 2012 at 02:54:43PM -0700, Marcel Moolenaar wrote: > On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > > Or are you suggesting to > > convince all BIOS vendors to include the ability to boot from some kind > > of FreeBSD private partitioning scheme (not MBR as it is not > > suitable, not GPT as you are not OK to use it on a gmirror)? >=20 > I would be having less problems if the mirroring didn't force the backup > GPT header in anything but the last sector. [...] GPT backup header is placed in the last sector of the mirror device, just like the user asked. Gmirror doesn't force anything. User decides to put GPT partitioning on the mirror device instead of raw disk. Gmirror doesn't even know and doesn't have to know how the user uses data area on the mirror device. > [...] If the metadata was somewhere > else, then we wouldn't need to kluge various places to deal with the > ambiguity and visible interoperability problems of the various tools and > OSes. [...] Where is "somewhere else", exactly? If somewhere else on this disk, then where? At the begining of the disk? Then you would complain that it keeps metadata where the primary header should be located and also MBR metadata, BSDlabel metadata, etc. Somewhere in the middle of the disk? Some future GPTng may want to use the same spot, but also gmirror-unaware boot loader will see corrupted data (shifted by one sector). Come on... If somewhere else is not on this disk, then I'm sorry, but this is totally impractical. Disks are the place you store stuff. In 99% of the cases there is no other place to store it, but the disk itself. Should we ask users to use additional disk to keep mirror's metadata? > [...] Thus, it's not that I object to the mirroring per se, just to the > mirroring as it is currently implemented with gmirror. Do you know software RAID (>=3D1) or volume manager that doesn't keep metadata on component disks? PS. We are discussing two totally different things here: 1. Is placing GPT on anything but raw disk violates the spec? I can agree that it does and I'm happy with gpart(8) growing a warning. 2. How to do software mirroring. Besides trying really hard I'm not sure what alternative are you proposing. Could you be more specific and describe how gmirror should be implemented in your opinion? > > What about multipathing? In case the disk is attached via two paths but > > multipath is not enabled, the OS sees the same disk (and the same > > identical unique disk identifier) multiple times. Is this a violation > > of the spec too? >=20 > It's the same disk, isn't it? The OS can actually use the property > of the ID to infer that it has already seen this disk and not create > multiple device nodes. You cannot trust some id that is found on disk to be unique, as all your assumptions break when the user decides to dd(1)-copy content of this disk to another disk, for example. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAk/s460ACgkQForvXbEpPzRTGwCfTL2ATAwe2abfVXK56cmuJocw R10An0aub6mww15UVaL2CrI3ao8Ohu9k =7Mep -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120628230725.GB1438>