Re: XFS filesystem recovery from secondary superblocks

[Dave Chinner <david@fromorbit.com>]

On Tue, Oct 30, 2012 at 10:02:28PM -0700, Aaron Goulding wrote:
> Hello! So I have an XFS filesystem that isn't mounting, and quite a long
> story as to why and what I've tried.
> 
> And before you start, yes backups are the preferred method of restoration
> at this point. Never trust your files to a single FS, etc.

It's kind of assumed knowledge round here or that there are good
reasons for not backing up the filesystem (e.g. it's hard to back up
a 500TB filesystem).

[snip raid horror story]

> Once I had the file created, I tried xfs_clean -f /mnt/restore/md0.dat to
> no luck. I used a hex editor to add XFSB to be beginning, hoping the

That won't work - the magic number is just one of many checks on the
superblock before it can be considered valid.

> recovery would just clean around the LVM data with similar results. The
> result looks like the following:
> 
> Phase 1 - find and verify superblock...
> bad primary superblock - bad or unsupported version !!!

And that's the second check :/

> attempting to find secondary superblock...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> unable to verify superblock, continuing...
> ....................................................................................................
> Exiting now.

So, that means if found 10 potential secondary superblocks, but
couldn't validate any of them. Can you find those superblocks and
hexdump them? something like: 

hexdump <dev or file> | grep -A 30 XFSB

Also of interest would be to hexdump the subsequent sector as well,
it should have a magic number of XAGF, and will also have a sequence
number in it that should help tell us if you've got everything in
order.

> running xfs_db /mnt/restore/md0.dat would appear to run out of memory.

No surprise there if the superblocks are toast.

> Next I tried xfs_db /dev/md1 to see if anything would load. I get the
> following:
> 
> root@jarvis:/mnt# xfs_db /dev/md1
> Floating point exception
> 
> With the following in dmesg:
> 
> [1568395.691767] xfs_db[30966] trap divide error ip:41e4b5 sp:7fff5db8ab90
> error:0 in xfs_db[400000+6a000]

what version are you running?

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

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