Re: [edk2] GPT Partitions on RAID Disks

[Robinson, Herbie]

I wanted to hold off on responding to this for a while to see if anyone else 
chimed in and because it required quite a bit of thought.  In the end I thought 
I should probably post what I ended up doing in case anyone scans the e-mail 
archives.  [I edited the awful quoting job this employer mandated e-mail client 
does to hopefully make it a little more readable.]

Background:

I have been tasked with implementing UEFI boot in our VOS operating system.  
We've been using GPT partitions for more than 15 years, but only within our own 
OS...  We haven't had to interact with any other software before this.  We have 
a fault tolerant OS; so, all disks are RAID1 (software supported).  We don't 
expose the GPT partitioning to our user interface:  We have just use it as a 
wrapper for boot support to keep BIOS from being confused.  The intent was to 
set it up to boot with either the legacy BIOS or UEFI.  At the time, we only 
had a legacy BIOS to test with; so, we never finished the UEFI boot.

I've reviewed our current implementation and found a few minor things wrong; 
so, I have been working on a utility to fix them.  But the might be some more 
issues.  I have three questions, but relating to RAID 1.

1.   We have historically paired entire disks when we do RAID1, not 
partitions (we have never supported multiple file system partitions on one 
disk, because it didn't make sense from a performance standpoint).  I believe 
the current initialization uses the same DiskGUID in the GPT header for both 
disks.  I'm assuming that is not going to work properly.  Is that correct?
[Andrew Fish] Herbie,

I'm not sure that a unique  DiskGUID is required for RAID1 given the disks are 
mirrors. I think the ask is that each unique GPT (some software has to create 
it) always gets a new GUID/UUID.
[Robinson, Herbie] I ended up deciding that the GPT partitions should be unique 
and that only the contents of our specific partition should be treated as 
mirrored.  The main reasoning behind this was because the UEFI firmware (and 
third party tools) wouldn't treat the GPT partitions as paired and update them 
simultaneously - If anything, the firmware would just be confused by the 
duplicated GUIDs.  Another factor is that the disks could be different sizes.  
Also, one would also be obligated to keep the ESPs in sync.  It would entail a 
lot more work, might not be compatible with other software and wouldn't really 
buy anything useful functionally.

3.   We have learned over the years that one doesn't allocate an entire 
disk for a RAID (because one may have to replace a drive and replacement may 
not come with exactly the same ending LBA).  We are currently leaving off some 
space at the end.  When we do that, we are not putting the backup GPT header at 
the last LBA the devices.  By my reading of the spec, that is a mistake.  I do 
believe the spec allows me to leave a large gap between the LastUsableLBA in 
the backup GPT header with the backup table placed anywhere within that gap.  
Is that correct?
[Andrew Fish] There has been language added over the years to try to help 
people deal with issues like this. The ATA8-ACS language and this section:
"To avoid the need to determine the physical block size and the optimal 
transfer length granularity, software may align GPT partitions at significantly 
larger boundaries. For example, assuming logical block 0 is aligned, it may use 
LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB) boundaries, 
which supports most common physical block sizes and RAID stripe sizes."

I think the "software may align GPT partitions at significantly larger 
boundaries." in the section above grants you a lot of latitude about how you 
layout the disks.
[Robinson, Herbie] I did, in fact leave a large hole between the backup 
partition table and the backup GPT header and at least our bios is happy with 
it.

And again, thanks for the help.


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] GPT Partitions on RAID Disks

[Andrew Fish]

> On Jul 3, 2018, at 10:12 AM, Robinson, Herbie  
> wrote:
> 
> Background:
> 
> I have been tasked with implementing UEFI boot in our VOS operating system.  
> We've been using GPT partitions for more than 15 years, but only within our 
> own OS...  We haven't had to interact with any other software before this.  
> We have a fault tolerant OS; so, all disks are RAID1 (software supported).  
> We don't expose the GPT partitioning to our user interface:  We have just use 
> it as a wrapper for boot support to keep BIOS from being confused.  The 
> intent was to set it up to boot with either the legacy BIOS or UEFI.  At the 
> time, we only had a legacy BIOS to test with; so, we never finished the UEFI 
> boot.
> 
> I've reviewed our current implementation and found a few minor things wrong; 
> so, I have been working on a utility to fix them.  But the might be some more 
> issues.  I have three questions, but relating to RAID 1.
> 
> 
> 1.   We have historically paired entire disks when we do RAID1, not 
> partitions (we have never supported multiple file system partitions on one 
> disk, because it didn't make sense from a performance standpoint).  I believe 
> the current initialization uses the same DiskGUID in the GPT header for both 
> disks.  I'm assuming that is not going to work properly.  Is that correct?
> 

Herbie,

I'm not sure that a unique  DiskGUID is required for RAID1 given the disks are 
mirrors. I think the ask is that each unique GPT (some software has to create 
it) always gets a new GUID/UUID. 

> 2.   The spec also seems to say that the UniquePartitionGUID should also 
> be different for RAID 1 pairs.  Is that correct?
> 

Same as DiskGUID is it a true mirror or unique disk? In a practical sense if 
some one could bit copy a disk you could have duplicates. The hope is that any 
software that is GPT aware would fix up the Unique GUID/UUID values as part of 
the cloning operation. 

> 3.   We have learned over the years that one doesn't allocate an entire 
> disk for a RAID (because one may have to replace a drive and replacement may 
> not come with exactly the same ending LBA).  We are currently leaving off 
> some space at the end.  When we do that, we are not putting the backup GPT 
> header at the last LBA the devices.  By my reading of the spec, that is a 
> mistake.  I do believe the spec allows me to leave a large gap between the 
> LastUsableLBA in the backup GPT header with the backup table placed anywhere 
> within that gap.  Is that correct?
> 

There has been language added over the years to try to help people deal with 
issues like this. The ATA8-ACS language and this section:
"To avoid the need to determine the physical block size and the optimal 
transfer length granularity, software may align GPT partitions at significantly 
larger boundaries. For example, assuming logical block 0 is aligned, it may use 
LBAs that are multiples of 2,048 to align to 1,048,576 byte (1 MiB) boundaries, 
which supports most common physical block sizes and RAID stripe sizes."

I think the "software may align GPT partitions at significantly larger 
boundaries." in the section above grants you a lot of latitude about how you 
layout the disks. 

Caveat Emptor if you need to be interoperable with other chunks of software as 
there can be extra non-spec assumptions that leak into implementations. The 
last one that I got hit by was most of the EFI code in the world require a 
protective MBR, but the spec uses may (not required) when talking about if a 
protective MBR is required. 

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L265

  //
  // Verify that the Protective MBR is valid
  //
  for (Index = 0; Index < MAX_MBR_PARTITIONS; Index++) {
if (ProtectiveMbr->Partition[Index].BootIndicator == 0x00 &&
ProtectiveMbr->Partition[Index].OSIndicator == PMBR_GPT_PARTITION &&
UNPACK_UINT32 (ProtectiveMbr->Partition[Index].StartingLBA) == 1
) {
  break;
}
  }
  if (Index == MAX_MBR_PARTITIONS) {
goto Done;
  }



Thanks,

Andrew Fish

> Thanks in advance for your guidance.
> Herbie Robinson
> Software Architect
> Stratus Technologies | www.stratus.com
> 5 Mill and Main Place, Suite 500 | Maynard, MA 01754
> T: +1-978-461-7531 | E: herbie.robin...@stratus.com
> [Stratus Technologies]
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] GPT Partitions on RAID Disks

[Robinson, Herbie]

Background:

I have been tasked with implementing UEFI boot in our VOS operating system.  
We've been using GPT partitions for more than 15 years, but only within our own 
OS...  We haven't had to interact with any other software before this.  We have 
a fault tolerant OS; so, all disks are RAID1 (software supported).  We don't 
expose the GPT partitioning to our user interface:  We have just use it as a 
wrapper for boot support to keep BIOS from being confused.  The intent was to 
set it up to boot with either the legacy BIOS or UEFI.  At the time, we only 
had a legacy BIOS to test with; so, we never finished the UEFI boot.

I've reviewed our current implementation and found a few minor things wrong; 
so, I have been working on a utility to fix them.  But the might be some more 
issues.  I have three questions, but relating to RAID 1.


1.   We have historically paired entire disks when we do RAID1, not 
partitions (we have never supported multiple file system partitions on one 
disk, because it didn't make sense from a performance standpoint).  I believe 
the current initialization uses the same DiskGUID in the GPT header for both 
disks.  I'm assuming that is not going to work properly.  Is that correct?

2.   The spec also seems to say that the UniquePartitionGUID should also be 
different for RAID 1 pairs.  Is that correct?

3.   We have learned over the years that one doesn't allocate an entire 
disk for a RAID (because one may have to replace a drive and replacement may 
not come with exactly the same ending LBA).  We are currently leaving off some 
space at the end.  When we do that, we are not putting the backup GPT header at 
the last LBA the devices.  By my reading of the spec, that is a mistake.  I do 
believe the spec allows me to leave a large gap between the LastUsableLBA in 
the backup GPT header with the backup table placed anywhere within that gap.  
Is that correct?

Thanks in advance for your guidance.
Herbie Robinson
Software Architect
Stratus Technologies | www.stratus.com
5 Mill and Main Place, Suite 500 | Maynard, MA 01754
T: +1-978-461-7531 | E: herbie.robin...@stratus.com
[Stratus Technologies]

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel