bug-parted
[Top][All Lists]
Advanced

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

Re: 4000GB partition becoming 1801GB after reboot?


From: Isolationism
Subject: Re: 4000GB partition becoming 1801GB after reboot?
Date: Mon, 03 Nov 2008 12:22:13 -0500
User-agent: Thunderbird 2.0.0.17 (X11/20081023)

Hi Joel, thanks for taking a few minutes to read and reply to my plea.

> Try GPT partitions.

My priority is to recover several weeks' worth of personal data that is
almost certainly still present on the array, not to get the array working
again. The important unanswered question is, "How could this happen"?

The only two explanations I can conceive for encountering the problem in the
first place are:

1) Since gpt and msdos partition tables can coexist on a device due to
different physical locations (modern macs do it all the time), some
applications may be confused/misled about which partition table to read/use,

OR

2) A GPT partition was never created in the first place, in which case parted
not only happily let me create an illegally large msdos partition, but also
proceed to use it for a month with absolutely no problems whatsoever -- that
is, until the machine was rebooted (see the link in my reply to Håkon;
someone else has reported precisely this problem in this list earlier this 
year).

I know for certain that I originally partitioned the drive using fdisk, which
would ensure that an msdos label is present on the drive regardless of any
other partition tables present; my reaction to the limited disk size was how
I came across parted at all.

Back to your suggestion: if I run `parted /dev/sdb mklabel gpt` and I'm
dealing with case #2 above, it seems a lot less likely that the data will
ever be recoverable. Conversely, if the first case applies then restoring
normal access to the drive should involve little more than "zapping" the
msdos label so that whatever software is detecting it now will ignore it and
find the gpt label instead.

My point is, before doing anything destructive to the data on the drive, I
want to determine which of the two points above is the case. I have a strong
suspicion that it is #1, but I don't have the technical knowledge to be able
to tell whether or not this is the case with any level of certainty.

At present, I have two goals:

1) With someone's generous help, conclude whether the problem is one case or
the other with some degree of certainty, and select an appropriate strategy
to attempt to recover the drive's data; and

2) Assist in resolving whatever defect is responsible for encountering this
issue in the first place to prevent similar misfortune/frustration from
befalling others.

Cheers,
Kevin Williams







reply via email to

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