On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The "fsck" would just check the checksums of primary
& secondary tables, and if an error in either (but not both) is
detected it would restore from the other one?
Yes. I think the exception to fixing would be if the MBR is clearly not a protective MBR,
i.e. it does not at all have an 0xEE entry. In that case, I'd say leave the stale GPT
info alone as the disk is MBR not GPT.
There are some challenges interpreting hybrid MBRs correctly, because there's no
standard here. So if the MBR contains an 0xEE entry and at least one additional entry, we
could safely fix an invalid GPT with information from the valid GPT so long as the entries
in the MBR and the valid GPT agree. If they don't, all bets are off and we probably
shouldn't touch anything.
Does such an "fsck"
tool exist already or would you just run gdisk (doesn't appear
to be automatic)?
Does not exist as far as I know. Much of this code is in parted, including recognizing
stale GPTs (a formerly GPT disk that's repartitioned MBR; which does not wipe out the
old GPT information).