So I’ve been doing some thinking on why the mac has problems with expanded volumes. By expanded volumes, i mean a volume that gets bigger after initial creation. This isn’t an issue for physical disks, since their size is set. But virtual volumes, such as those presented by a RAID card can be “grown” through raid magical goodness.Once they’ve been grown - someone/something needs to update the GPT headers to say “this disk is much larger than before”. Part 1 accomplishes that through destroying the GPT headers, and re-creating them. It works, but man is it nerve-wracking.The other way one could do this, is by directly editing the GPT headers.In the GPT headers there are some fields:
FirstUsableLBA
The first usable logical block that may be used by a partition described by a GUID Partition Entry.
LastUsableLBA
The last usable logical block that may be used by a partition described by a GUID Partition Entry.
AlternateLBA
LBA address of the alternate GUID Partition Table Header.
HeaderCRC32
CRC32 checksum for the GUID Partition Table Header structure. This value is computed by setting this field to 0, and computing the 32-bit CRC for HeaderSize bytes.
What has to get updated is that LastUsableLBA and AlternateLBA. AlternateLBA should be = the last block on the hard drive.LastUsableLBA should be something like AlternateLBA-32.Once you’ve updated these, you have to calculate a new CRC32 checksum.If you’re a good person, you would go ahead and write the alternate header to the end of the disk - a bad person would just let the OS panic about the lack of backup headers and fix it itself.I’ll be doing some testing of this over the coming weeks, and i’ll let you know what i find.