Re: [CFC/CFT] large changes in the loader(8) code

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