From owner-freebsd-current@FreeBSD.ORG Thu Jun 28 09:23:57 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADD071065679 for ; Thu, 28 Jun 2012 09:23:57 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm2-vm0.bullet.mail.ukl.yahoo.com (nm2-vm0.bullet.mail.ukl.yahoo.com [217.146.183.226]) by mx1.freebsd.org (Postfix) with SMTP id E6D748FC12 for ; Thu, 28 Jun 2012 09:23:56 +0000 (UTC) Received: from [217.146.183.211] by nm2.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [77.238.184.61] by tm4.bullet.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 Received: from [127.0.0.1] by smtp130.mail.ukl.yahoo.com with NNFMP; 28 Jun 2012 09:23:49 -0000 X-Yahoo-Newman-Id: 477533.38404.bm@smtp130.mail.ukl.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aj1_ABcVM1m_bKiy7nT6Mb_DPxf6oducw7_286ALLjHzzwu qweB9qDvd8URveHB3u028SpgZY8BTFwjnP2Q_2SAmgIeN9Rv3TSaRwpzYcKu jBqc2487vOvgQ3Shk0w_P2BjMbjDYbydycicWTv1Y4XZ3ZnFbFZUs9XfJKhd KX1etpFsfCU4fF1S0ygy8amqbhL62zEHVEQJg6GTGLXXhH5kXJRXtv4jD3qS uIFsntB68FpA8DCj_okZedZjBNuVr3cJyri0uiCplRuhdBRX8whgmWUp_6EC .Wi_xnmM90h8QS_.lkPnEzTDIcIhJ7K._62M.0.ud5h668qjXpK4ORxLA0FO gyN5mhCa06v3K_7Gml_MJ8zm7ZAH4CzHLc6V_PbMu8639GnSI0.pKehW74TY LgxozpK42wrkMmLX58Msm X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp130.mail.ukl.yahoo.com with SMTP; 28 Jun 2012 09:23:44 +0000 GMT Message-ID: <4FEC22A0.9000109@freebsd.org> Date: Thu, 28 Jun 2012 11:23:44 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar 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> In-Reply-To: <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 09:23:57 -0000 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 <> GMIRROR Configuration and State <> (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