From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=216.205.24.131; helo=us-smtp-delivery-131.mimecast.com; envelope-from=herbie.robinson@stratus.com; receiver=edk2-devel@lists.01.org Received: from us-smtp-delivery-131.mimecast.com (us-smtp-delivery-131.mimecast.com [216.205.24.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3985C203369D1 for ; Mon, 9 Jul 2018 17:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=StratusTechnologies.onmicrosoft.com; s=selector1-stratus-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9lMMUTjlw+z/y+QfS3Y6FUvCXptkvnt/MMFfaot0f5A=; b=NJjHBRInWqB1R9BRM7pWT3oVWUj4/1s3PzIfbFh+tNFsMWY3A1nTDhR35ITyjGr5awBeM0eE8O8nbX/SIWWQCWFOAzz8D0H6GNVJSMX1gBYIDbJ4anMJzMB0zDXhULtqWQUAe17Qf+aJ7aEHHIBm55HtdMqSew6yaZx7CrHd7Gc= Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05lp0115.outbound.protection.outlook.com [216.32.181.115]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-187-4mkH8u8BOUGE3VCRzjNJ_A-1; Mon, 09 Jul 2018 20:20:35 -0400 Received: from BN1PR08MB107.namprd08.prod.outlook.com (10.242.212.20) by BN1PR08MB202.namprd08.prod.outlook.com (10.255.206.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.19; Tue, 10 Jul 2018 00:20:30 +0000 Received: from BN1PR08MB107.namprd08.prod.outlook.com ([fe80::cd92:8f36:3813:4f02]) by BN1PR08MB107.namprd08.prod.outlook.com ([fe80::cd92:8f36:3813:4f02%13]) with mapi id 15.20.0930.022; Tue, 10 Jul 2018 00:20:30 +0000 From: "Robinson, Herbie" To: "afish@apple.com" CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] GPT Partitions on RAID Disks Thread-Index: AdQS5hbVjgw0qMUKRfa18LmaNMJwWgAJoQQAATUuFqA= Date: Tue, 10 Jul 2018 00:20:30 +0000 Message-ID: References: <14936E0D-1287-4716-AC45-5CEDEC774A0F@apple.com> In-Reply-To: <14936E0D-1287-4716-AC45-5CEDEC774A0F@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.97.42.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN1PR08MB202; 7:phEcELOWwyFAEL2JWmIJmB6R8nmTXvjlqt3Znro4Cg/3BsVDyFA8e8eqIpM9iTpwfzAFGE36S1laQrSMMNYVWnJL9FRp6vwrL1lU3hgUbGku8IFzTounqf9oPBqTK6ivn2nPIbfujNgvTpaWKN3AVX/eK0Czu1z1qS23BGFk1OupPgC3o5PV+g6/MyPuUwqslHiI0QHU3qqKakg6KadzzTjw4WdlXsTZ1AW7dd0K5k7XM0yrzfTUziQ/NXI/9e3I; 20:il07sSqTf+/TyawzkIueTR2yVxncU6t5QFprLGn/UBHLo5PVQ2O2AmkHb0bqFxplVG1VocrPRIE19tiz+0NeaJ9nifw2g2hOZRzZYPn0k/PDqLkV65lbMivtLy5LhBcPnrQs51rI7DbuXJD8xu7z8za7vCwGCIE8gWuNpPyoXmc= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ee1b63d7-c09b-489e-4199-08d5e5faf1ee x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:BN1PR08MB202; x-ms-traffictypediagnostic: BN1PR08MB202: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(35073007944872)(788757137089)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN1PR08MB202; BCL:0; PCL:0; RULEID:; SRVR:BN1PR08MB202; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(39850400004)(136003)(346002)(199004)(51914003)(189003)(6116002)(790700001)(3846002)(256004)(229853002)(2900100001)(19609705001)(8936002)(14444005)(5660300001)(6436002)(6306002)(9686003)(54896002)(55016002)(5640700003)(99286004)(6916009)(5630700001)(2351001)(68736007)(316002)(81156014)(81166006)(97736004)(25786009)(1730700003)(8676002)(26005)(105586002)(86362001)(7696005)(4326008)(72206003)(106356001)(11346002)(486006)(14454004)(186003)(476003)(446003)(2906002)(5250100002)(6246003)(2501003)(53936002)(66066001)(7736002)(6506007)(478600001)(33656002)(76176011)(74316002)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR08MB202; H:BN1PR08MB107.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:3; x-microsoft-antispam-message-info: Yo5CooAbqVm6QB2C9cVVkqlVfo5iGz2Xv6WahEswqE6Xv7l8/4X/n3N4prj21Y0zRPDZ4IsOfv9eveFpSVg5mrTUCrrCDOpj4Gc5OgQUNYh/ub61PlTOvk8WaXTKSxt7fNri/7z1i+aPavVZzNBk+aaz+rKYOzGhY637xebYujCIyPxRXU7yczNpXZuVrEkTlRvZ+nlPpnW8PyFtR3+KA0nViuKmCkQXw48gQBz1qRaUlmeaOv27sCzAh3SCHvtzpyLCER4U80fL+4tVYcWcFWWYqf1WBUC2MRsFXIOx48ibRNXXBrAEByKnUAf/ajA0F6/zkeipW9kHnNgKmlPnUe7iyE0IAMtKt4YBFK6fKgk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: stratus.com X-MS-Exchange-CrossTenant-Network-Message-Id: ee1b63d7-c09b-489e-4199-08d5e5faf1ee X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 00:20:30.5052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de36b473-b8ad-46ff-837f-9da16b8d1b77 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR08MB202 X-MC-Unique: 4mkH8u8BOUGE3VCRzjNJ_A-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.27 Subject: Re: GPT Partitions on RAID Disks X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 00:20:40 -0000 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I wanted to hold off on responding to this for a while to see if anyone els= e chimed in and because it required quite a bit of thought. In the end I t= hought I should probably post what I ended up doing in case anyone scans th= e 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 o= ur own OS... We haven't had to interact with any other software before thi= s. We have a fault tolerant OS; so, all disks are RAID1 (software supporte= d). We don't expose the GPT partitioning to our user interface: We have j= ust 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 par= titions (we have never supported multiple file system partitions on one dis= k, because it didn't make sense from a performance standpoint). I believe = the current initialization uses the same DiskGUID in the GPT header for bot= h 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 un= ique 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 up= date them simultaneously - If anything, the firmware would just be confused= by the duplicated GUIDs. Another factor is that the disks could be differ= ent 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 m= ay not come with exactly the same ending LBA). We are currently leaving of= f some space at the end. When we do that, we are not putting the backup GP= T 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 anywhe= re within that gap. Is that correct? [Andrew Fish] There has been language added over the years to try to help p= eople 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 tra= nsfer length granularity, software may align GPT partitions at significantl= y larger boundaries. For example, assuming logical block 0 is aligned, it m= ay 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 boun= daries." in the section above grants you a lot of latitude about how you la= yout the disks. [Robinson, Herbie] I did, in fact leave a large hole between the backup par= tition table and the backup GPT header and at least our bios is happy with = it. And again, thanks for the help.