2008/11/3 Isolationism <[EMAIL PROTECTED]>: > 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
_______________________________________________ bug-parted mailing list bug-parted@gnu.org http://lists.gnu.org/mailman/listinfo/bug-parted
