[Top][All Lists]

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

Re: 4000GB partition becoming 1801GB after reboot?

From: Håkon Løvdal
Subject: Re: 4000GB partition becoming 1801GB after reboot?
Date: Tue, 4 Nov 2008 00:54:36 +0100

2008/11/3 Isolationism <address@hidden>:
> 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"?

As pointed out elsewhere, the kernel does not have a 32bit limit while
the partition table has, and I am very sure this was the root cause.
My calculations below explains the existing number 99.9% accurately...

[A little warning first, I know very little about the
modern gpt format, and have mostly pulled information from
http://en.wikipedia.org/wiki/GUID_Partition_Table for this reply]

If the partition was to start at the next head after the MBR
(i.e. CHS=0/1/1) and span the whole remaining disk, then the size field
in the partition table should be 7812425502 or 0x1D1A8271E hex (which
is too big to fit in 32 bit and would be truncated to 0xD1A8271E). The
present number (3517442141) is 0xD1A7E85D hex. Although it is not a 100%
match, I think it is obvious that the size number for the partition has
been written and truncated in the table.

So the next step is to try to figure out the difference between the
perhaps expected 0xD1A8271E and the actual 0xD1A7E85D.

You said that you thought that you had created a GPT partition. Assuming
then that the fist 33 and last 32 LBAs are occupied because of that,
the partition could maybe start on LBA 34 or CHS=0/1/1 (LBA 63) and end
on LBA -34 (LBA 7812409466) or CHS=486298/255/63 (LBA 7812393497).

The two first combinations are the two "sane" combinations, the last
two are only included for completeness.

7812393497 - 63 + 1 = 7812393435 = 0x1D1A7A9DB
7812409466 - 34 + 1 = 7812409433 = 0x1D1A7E859
7812393497 - 34 + 1 = 7812393464 = 0x1D1A7A9F8
7812409466 - 63 + 1 = 7812409404 = 0x1D1A7E83C

Now we are very close! 0xD1A7E859 and 0xD1A7E85D differs only 4 sectors. I
do not know what this is caused by and it feels a little bit discomforting
that the actual number present was larger than the number I calculated
as maximum. Have I made some miscalculations above?

But in any case it feels very likely that the partition starts at LBA 34,
and I assume that it should be possible to read out information in the
first GPT entry in LBA 2 (and/or LBA -33) and check that as well.

Another rescue option - other than playing Sherlock Holmes
with the entries in the partition table - is to use tools for
detecting file system which just reads the disk raw, searching
for possible start entries for a file system. There are probably
several options for this but I would have started with gpart,
http://www.stud.uni-hannover.de/user/76201/gpart/. Maybe also it would
be possible "brute force" the few possible partition starting points,
creating (dummy) partition entries and feed to xfsdump, xfs_metadump or
xfs_repair or something similar.

I see that you were successful with using "parted rescue" for this,
so I guess your mission is accomplished. Just out of curiosity I would
like to see what the partition table looks like now, could you send
"printf x p" again?

BR Håkon Løvdal

reply via email to

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