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:It's kind of assumed knowledge round here or that there are good
> 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.
reasons for not backing up the filesystem (e.g. it's hard to back up
a 500TB filesystem).
[snip raid horror story]
That won't work - the magic number is just one of many checks on the
> 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
superblock before it can be considered valid.
And that's the second check :/
> 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 !!!
So, that means if found 10 potential secondary superblocks, but
> 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.
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.
No surprise there if the superblocks are toast.
> running xfs_db /mnt/restore/md0.dat would appear to run out of memory.
what version are you running?
> 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]
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
