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 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
