On 04/03/2013 05:54 PM, Elliott, Robert (Server Storage) wrote:
You're trying to lay out the disk as:
LBA 0 protective or hybrid MBR (required to be here)
LBA 1 GPT Header (required to be here)
LBA 2 restricted for some other purpose
LBA 3..m-1 GPT Partition Entry Array (size m-3)
LBA m First Usable LBA
...
LBA n-(m-3)-2 Last Usable LBA
LBA n-(m-3)-1..n-1 GPT Partition Entry Array (size m-3)
LBA n Alternate GPT Header (required to be here)
LBAs 0, 1, and n have fixed content; the other content can float.
Right - though for my use case the restricted area is more like 600 sectors.
The UEFI GPT specification allows for gaps between:
- the GPT Header and the GPT Partition Entry Array
- the GPT Partition Entry Array and the First Usable LBA
- the Last Usable LBA and the alternate GPT Partition Entry Array
- the alternate GPT Partition Entry Array and the alternate GPT Header
but doesn't remember the gaps used by one GPT in the other GPT.
If the primary GPT Header goes bad and the primary GPT is rewritten
by copying the alternate GPT Header and alternate GPT Partition
Entry Array back into the primary location, how would software know that it is
not supposed to place the Partition Entry Array at LBA 2? The software doing
this may or may not understand the special case.
A very good point I'd not thought of. I don't think U-Boot currently
does anything with the alternate header, so I didn't consider that.
There is no rule in the UEFI GPT specification that there be the same spacing
between the alternate GPT Header and the alternate GPT Partition Entry Array
and the alternate Header as there is between the primary GPT Header and the
primary GPT Partition Entry Array, but that might be a way to communicate
this need. We could try to add such a rule if that's the only viable solution.
That seems to be a good idea to me. I can't think of any better way to
"back up" that offset information. It's a little wasteful of space though.
+++ b/libparted/labels/gpt.c
last_usable_if_grown
- = (disk->dev->length - 2 -
+ = (disk->dev->length - gpt->PartitionEntryLBA -
((PedSector) (PED_LE32_TO_CPU (gpt->NumberOfPartitionEntries)) *
(PedSector) (PED_LE32_TO_CPU (gpt->SizeOfPartitionEntry)) /
disk->dev->sector_size));
Does this leave room for the alternate GPT (Header and Partition Entry
Array)? It seems to be missing a "2 *" factor.
Actually a bug in the initial patch... I shouldn't have changed that
line at all. using gpt->PartitionEntryLBA directly was also a bad move.
I've rewritten the patch to make the gap be the same for both primary
and alternate partition entries, and fixed up some other fairly ugly
problems that would allow creating partitions that overlap with the
partition tables.
I'll post that shortly
Thanks,
Derek