Date: Thu, 28 Jun 2012 11:23:44 +0200 From: Stefan Esser <se@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Doug Rabson <dfr@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, Pawel Jakub Dawidek <pjd@freebsd.org>, Christian Laursen <xi@borderworlds.dk>, freebsd-hackers <freebsd-hackers@freebsd.org>, Andriy Gapon <avg@freebsd.org>, freebsd-current <freebsd-current@freebsd.org>, "Andrey V. Elsukov" <bu7cher@yandex.ru> Subject: Re: [CFC/CFT] large changes in the loader(8) code Message-ID: <4FEC22A0.9000109@freebsd.org> In-Reply-To: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 27.06.2012 21:14, schrieb Marcel Moolenaar: > > On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote: > >> On 06/27/12 16:28, John Baldwin wrote: >>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote: >>> >>>> When we are in the FreeBSD, our loader can detect that device size >>>> is lower than it see and it will work. When primary header is OK, then >>>> other OSes should work with this GPT. When it isn't OK, you just can't >>>> load other OS :) >>> >>> Ah, yes. The solution to violating standards is to make sure you never >>> use standards-compliant software. That's a great argument. :) >>> >>> (Although not entirely uncommon. Standards aren't always perfect, but if >>> we had a way to not gratuitously violate them it would be nice to avoid >>> doing so.) >> >> To be standards compliant and allow whole-disk based mirroring to work at the same time wouldn't nested GPT work like this? > > GPTs don't nest. It is not strictly necessary to use nested GPT to have GMIRROR et.al. and GPT co-exist. And I think this is possible without violation of any standard. Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: MBR or Primary GTP header <<User Data 1: [0 .. (End -32KB)]>> GMIRROR Configuration and State <<User Data 2: [(End -32KB) .. End]>> (Spare area for Sec. GPT header) If creating a GMIRROR (or other GEOM that keeps state at the end of the provider) left at least the last 32KByte untouched (33 GPT sectors rounded up to a power of 2), GPT could use this spare space to store its Secondary Header. These sectors could be treated as part of the User Data area, i.e. logical addresses would be translated by GMIRROR to skip the GMIRROR configuration sector (which I'd enlarge to at least 4KB for alignment of "User Data 2"). This implies that the GMIRROR specification covers the whole provider (including the spare space but without the sectors holding the GMIRROR config, which are "mapped out"), since updates to the Secondary GPT must be performed on all mirrored devices. This is a complication of the current GMIRROR code, but could be added without impact on existing disk layouts. (I have not checked, whether backwards compatibility mandates introduction of a new GMIRROR class that supports such spare space after the GMIRROR config data, but I assume that there is enough spare space pre-initialized to 0 that can be used to add a flag that declares the 32 KByte beyond the end of the config data to be part of the mirror.) The only modifications required are: - If a GMIRROR is created, place the configuration sector 32 KByte before the end of the provider and mark it as "GPT compatible". (It is unknown at this point, whether GPT is to be used on the mirror at a later time.) - Tasting a provider should support looking for a valid GMIRROR (or GRAID) config sector not only at the end of the provider, but if that fails then also 32 KByte before the end of the provider. The GMIRROR is considered to be the provider for the GPT (i.e. the GMIRROR extends to 32 KByte beyond its config sector). - Creating partitions with MBR or GPT within a GMIRROR is possible without modification. The only difference is that the protected GMIRROR configuration sector is physically within the range of sectors used for the partition, but logically mapped out. The space available for partitioning is the provider size minus the size of the GMIRROR configuration, just as it used to be. - Readind and writing the mirror is allowed for all sectors in the User Data area, as in a "normal" GMIRROR. The only difference is the test for logical sectors in the last 32 KByte, for which the request is modified to be offset by a few sectors to skip the GMIRROR configuration sector. Requests that cover physical sectors before and behind these GMIRROR config sectors must be split. If instead of splitting off the final 32 KByte as "User Data 2", just the 33 sectors (of 512 Byte) required for GPT were assigned to that area, then there would never be requests that extend beyond the GMIRROR config sectors on GPT partitioned disks. But since such request were still possible if MBR partitions were used, code to treat such requests was still required in GMIRROR. There is one caveat, though: Creating a GMIRROR and then using an OS that does not know about FreeBSD to partition the disk would result in the GMIRROR configuration space being ignored. Another problem could be, that the available space in the GPT is the size of the disk minus the GMIRROR configuration sectors, i.e. there is a difference between the number of physical sectors on the disk and the number of sectors to be assigned to partitions by GPT. >> Nothing but FreeBSD would understand the freebsd-geom partition >> type, so the inner GPT device should be valid and standards >> compliant. > > If it were standards compliant, it would be discoverable by non-FreeBSD. > That clearly isn't the case -- hence it's not standards compliant. What > for example if someone wanted to share the swap partition between Linux > and FreeBSD? My suggested modification to GMIRROR would be compatible with other operating systems use of partitions on such devices. They'd just see individual GPT partitioned disks. Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FEC22A0.9000109>