XFS filesystem recovery from secondary superblocks

[Aaron Goulding]

root at 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 at fromorbit.com> 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 at 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 at fromorbit.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20121107/c110ccc7/attachment.htm>