[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug-parted Digest, Vol 118, Issue 10

From: Rod Smith
Subject: Re: bug-parted Digest, Vol 118, Issue 10
Date: Sun, 23 Sep 2012 20:04:31 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120813 Thunderbird/10.0.6

On 09/23/2012 12:00 PM, address@hidden wrote:
>  Leaving that aside (assuming the authors mean "greater than
>  or equal to 92"), I don't read this as meaning that the
>  HeaderSize must be 92 for the current version of the GPT
>  table; it clearly states that the value must be BETWEEEN 92
>  and the logical block size. You could set HeaderSize to 92,
>  93, 122, or whatever, and it would be legal. There may be
>  something else in the spec that contradicts this reading,
>  though, and I've just missed it. There could also be some
>  subtle difference between the 2.3.1 spec and an earlier
>  spec.
I don't agree with this. The description for the "Reserved" field
clearly says that "The rest of the block is reserved by UEFI and must be
The size of "Reserved" field mentioned is "BlockSize - 92". So, for
current version the HeaderSize should not be> 92 (even if it is> 92, the
fields beyond 92 should all be zero.

I disagree. IMHO, the statement in the HeaderSize description about that field's legal values (adjusted for common sense in this case) should take precedence over any inferences you might draw based on a description of another field.

That said, I agree that there's a potential for harm should somebody write software that stores data past byte 92 in the GPT header's sector. Such software would clearly violate the spec, though. Note that, the last I checked, libparted trashes hybrid MBRs, which are standards-violating but that *DO* exist in the wild. This is analogous to zeroing out the post-92 bytes in the GPT header sector. Thus, I don't see much point in going out of the way, and creating problems with known software (zpool) in the process, to avoid what are currently purely hypothetical problems. My opinion might change if and when software that stores data past byte 92 actually appears in the wild.

This would of course be much simpler if the spec just said that HeaderSize should equal 92.

I also believe that in future if the headerSize is increased, its
Revision number should also be changed.

I agree, but that's something that I (and I'm guessing you) have no control over.

I agree there's no harm in reading tables that have HeaderSize>  92.
But, what about modifying them ? While modifying we change the
headerSize to 92 and all contents beyond 92 are lost.

Assuming the Revision value checks out, IMHO that's fine. The spec clearly states that values past 92 must be 0. Thus, if something else is there, no matter what the HeaderSize value states, it doesn't conform to the spec, and zeroing it out qualifies as a repair. That said, including code to check for this condition and giving the user the option of aborting or preserving this non-compliant data would be reasonable, too.

I've never heard of any tool that stores data in the post-92 reserved field of the GPT header. Thus, all this is very hypothetical at the moment. Since zpool *DOES* create disks with HeaderSize values of 512, though, something reasonable MUST be done with them.

Rod Smith

reply via email to

[Prev in Thread] Current Thread [Next in Thread]