bug-parted
[Top][All Lists]
Advanced

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

Re: Minimum size of GPT partition table header


From: rahul dev
Subject: Re: Minimum size of GPT partition table header
Date: Mon, 24 Sep 2012 14:44:16 +0800 (SGT)

> ...
> >> 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.

I agree there's no harm in reading such a table. But, parted must warn the user 
about the header size mismatch during any write operation and that the contents 
beyond 92 bytes would be lost.

Or can we read the original contets of header (beyond 92) and restore them 
during write operation ?



reply via email to

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