root@jarvis:~# xfs_db -V<br>xfs_db version 3.1.7<br><br>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. :)<br><br>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? <br>
<br>Thanks Again!<br><br>-Aaron<br><br><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 1, 2012 at 3:59 PM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Oct 30, 2012 at 10:02:28PM -0700, Aaron Goulding wrote:<br>
> Hello! So I have an XFS filesystem that isn't mounting, and quite a long<br>
> story as to why and what I've tried.<br>
><br>
> And before you start, yes backups are the preferred method of restoration<br>
> at this point. Never trust your files to a single FS, etc.<br>
<br>
</div>It's kind of assumed knowledge round here or that there are good<br>
reasons for not backing up the filesystem (e.g. it's hard to back up<br>
a 500TB filesystem).<br>
<br>
[snip raid horror story]<br>
<div class="im"><br>
> Once I had the file created, I tried xfs_clean -f /mnt/restore/md0.dat to<br>
> no luck. I used a hex editor to add XFSB to be beginning, hoping the<br>
<br>
</div>That won't work - the magic number is just one of many checks on the<br>
superblock before it can be considered valid.<br>
<div class="im"><br>
> recovery would just clean around the LVM data with similar results. The<br>
> result looks like the following:<br>
><br>
> Phase 1 - find and verify superblock...<br>
> bad primary superblock - bad or unsupported version !!!<br>
<br>
</div>And that's the second check :/<br>
<div class="im"><br>
> attempting to find secondary superblock...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> unable to verify superblock, continuing...<br>
> ....................................................................................................<br>
> Exiting now.<br>
<br>
</div>So, that means if found 10 potential secondary superblocks, but<br>
couldn't validate any of them. Can you find those superblocks and<br>
hexdump them? something like:<br>
<br>
hexdump <dev or file> | grep -A 30 XFSB<br>
<br>
Also of interest would be to hexdump the subsequent sector as well,<br>
it should have a magic number of XAGF, and will also have a sequence<br>
number in it that should help tell us if you've got everything in<br>
order.<br>
<div class="im"><br>
> running xfs_db /mnt/restore/md0.dat would appear to run out of memory.<br>
<br>
</div>No surprise there if the superblocks are toast.<br>
<div class="im"><br>
> Next I tried xfs_db /dev/md1 to see if anything would load. I get the<br>
> following:<br>
><br>
> root@jarvis:/mnt# xfs_db /dev/md1<br>
> Floating point exception<br>
><br>
> With the following in dmesg:<br>
><br>
> [1568395.691767] xfs_db[30966] trap divide error ip:41e4b5 sp:7fff5db8ab90<br>
> error:0 in xfs_db[400000+6a000]<br>
<br>
</div>what version are you running?<br>
<br>
Cheers,<br>
<br>
Dave.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</font></span></blockquote></div><br></div>