Re: need help to repair XFS partition

[Eric Sandeen <sandeen@sandeen.net>]

Gergely Soos wrote:
> In my original email there was an attachment that contained the original
> boot sector, but anyway, here comes the hexdump Eric asked for:

Sorry, didn't open the tarfile :)

> 00000000  91 f0 1c 43 90 01 ba bf  f7 ee 29 9a 1e 6c d5 aa
> |.ð.C..º¿÷î)..lÕª|
> 00000010  11 5a 12 cb 3b 29 cb ff  39 ce 4e d3 95 ec b9 39
> |.Z.Ë;)Ëÿ9ÎNÓ.ì¹9|

...

> This looks like nothing to me...

I agree... something splattered on the disk it seems.  How far does this
junk go on, I wonder?

> xfs_repair rejects all superblock candidates and exits saying something
> like: Sorry, cannot find valid secondary superblock.
> I'm not sure what a GPT is, but this is an IDE harddisk, I'm using kernel
> 2.6.20 and my xfs partition is /dev/hdd1

GPT is a disk partitioning scheme, and it puts backups at the end of the
disk (IIRC), which sometimes automatically gets restored to the front.
But this does not look like your case.

> Is there any way xfs_repair would accept the superblock as is and move on
> with the repairs?

Well, you want to be sure it matches.  But - go looking through your
disk for "XFSB" and keep track of where the offsets are; you should find
your backup superblocks that way, and we can use xfs_db to get the
values out and perhaps restore your primary.

(you can probably do this on your own, but something like:
# dd if=/dev/hdd1 bs=4k | hexdump -C | grep XFSB
might do nicely)

xfs_repair should be better at using these by itself.  If you can put
your metadump somewhere that I can get to it, maybe I can look and see
why repair is not succeeding...

-Eric

> Gergely
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs