Re: Minimum size of GPT partition table header

[Jim Meyering]

rahul dev wrote:
...
>> Has this code caused an actual problem for you?
>
> One more question here.
> Should we allow read of gpt table in case the header size > 92 ? This
> is because if the header size has been increased, the header revision
> should also be increased. So, we should fail reading such a partition
> table (saying hdr revision not supported).
> Even if allow reading such a table, we should not allow any
> modifications to it. While writing the gpt header we modify the header
> size, so original contents (beyong 92 offset) will be
> lost/overwritten.

I think parted must accept header size > 92.
Currently parted can usefully read partition tables like
the one you mention below.

> I am seeing this problem for gpt partitions created by Solaris "zpool
> create" command. It creates a gpt hdr with size 512 bytes (but doesn't
> change the revision which is incorect). Apart from this it has only 9
> partition table entries (which doesn't comply with the EFI
> spec). Moreover, it doesn't place the backup gpt at the end of
> disk. Using libparted, I can read this table. But, if I modify such a
> table the original gpt hdr contents are lost.
>
> I feel that we should fail both read/write of a table whose hdr size >
> 92. What's your opinion ?

Reading such a partition table must be possible.
Like any writing operation, one should be careful to save backups.
I guess in this case, parted could issue a diagnostic about the mismatch.

However, I feel strongly that even the possibility of a write
operation (even after a prompt that asks if it's ok) during a nominally
read-only task, should be eliminated.  For example, currently just listing
a GPT partition table may lead to parted asking you if you'd like to
reposition the backup header.  That happens only when not using -s.
Having a separate option to repair a partition table would be fine.
Having that option enabled during a read-only operation like "list" is not.