public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Robinson, Herbie" <Herbie.Robinson@stratus.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: GPT Partitions on RAID Disks
Date: Tue, 3 Jul 2018 17:12:35 +0000	[thread overview]
Message-ID: <BL2PR08MB1007A308E0FF32064F95FA6E6420@BL2PR08MB100.namprd08.prod.outlook.com> (raw)

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>



             reply	other threads:[~2018-07-03 17:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03 17:12 Robinson, Herbie [this message]
2018-07-03 20:29 ` GPT Partitions on RAID Disks Andrew Fish
2018-07-10  0:20   ` Robinson, Herbie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BL2PR08MB1007A308E0FF32064F95FA6E6420@BL2PR08MB100.namprd08.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox