Re: XFS filesystem recovery from secondary superblocks

[Aaron Goulding <aarongldng@xxxxxxxxx>]

root@jarvis:~# xfs_db -V
xfs_db version 3.1.7

I'm sorry for the delay in response. I've had to work on several other projects as well, and thank you for the assistance. :)

So I ran a check using bgrep to find all instances of XFSB on /dev/md1 and came up with just over 3000 results. It's easy enough to write up something to go grab 100-200 bytes at each point, but I wonder if there's something I can improve on the bgrep search to narrow that result list down a bit? 

Thanks Again!

-Aaron

On Thu, Nov 1, 2012 at 3:59 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:

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@xxxxxxxxxxxxx