GPT Partitions on RAID Disks

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.Robinson@stratus.com
[Stratus Technologies]<http://go.stratus.com/US>

Re: GPT Partitions on RAID Disks

[Andrew Fish]

> On Jul 3, 2018, at 10:12 AM, Robinson, Herbie <Herbie.Robinson@stratus.com> 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.Robinson@stratus.com
> [Stratus Technologies]<http://go.stratus.com/US>
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: 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.