xfs
[Top] [All Lists]

Re: XFS filesystem recovery from secondary superblocks

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS filesystem recovery from secondary superblocks
From: Aaron Goulding <aarongldng@xxxxxxxxx>
Date: Wed, 7 Nov 2012 07:24:03 -0800
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RmqLweV/c3t3WPtvP1S5O+VPhlJG4aPNPNzakqsKONc=; b=xiQKq7oGcbegnW0L4QB6+4GlXXyzmgWJcxoQA659hVWclSCmxzi4o465kt/9O9hYuX cb/XlT+9zkxghSgkr5JL2zj1vAxzQaaMZG1MsddkEoIrDCdyzcb3OI6veij2QN/V5hSO Wf6Clulgpuf+v4thOzPxB2dgfClfrKiMGFOj1rTVMQ9MBfZ0HnvUkpmkmlZObAXLuH/P 5p/76YIu7X6eSP8tzPmtbINppCNQ5YZHrvsE2LmCxQneITn5wowRJvZmibxNZR/v8JkF NLebjr5EUs2ZX2So+xOpbgKQAlCzGzHZPhGDd4rmangiKn+QONSA8XLGpHb8ifZ0XttX TzGg==
In-reply-to: <20121101225938.GS29378@dastard>
References: <CABJyUz+h=pZ6+2rro1PjoB1ggTAoRw+bTzc_bU7Eaec0_AUKLA@xxxxxxxxxxxxxx> <20121101225938.GS29378@dastard>
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

<Prev in Thread] Current Thread [Next in Thread>