> On Jul 3, 2018, at 10:12 AM, Robinson, Herbie <herbie.robin...@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.robin...@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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
