Re: XFS filesystem recovery from secondary superblocks

[Dave Chinner <david@fromorbit.com>]

On Fri, Nov 09, 2012 at 07:22:01AM -0800, Aaron Goulding wrote:
> On Fri, Nov 9, 2012 at 2:48 AM, Dave Chinner <david@fromorbit.com> wrote:
> 
> > On Thu, Nov 08, 2012 at 11:28:20PM -0800, Aaron Goulding wrote:
> > > On Thu, Nov 8, 2012 at 1:02 PM, Dave Chinner <david@fromorbit.com>
> > wrote:
> > >
> > > > That seems like way too many to be filesystem metadata hits. I woul
> > > > dhave expected the same number of hits as there are AGs in the
> > > > filesytem. What you want is the XFSB string in the first 4
> > > > bytes of a sector, with the next sector having XAGF as the first
> > > > four bytes....
> > > >
> > >
> > > Okay this proved helpful. I ran a check of the first 1024 bytes at each
> > of
> > > those 19000 results for XAGF, then limited that to results that occurred
> > at
> > > the 512 byte relative mark. This dropped the results down to  11. I then
> > > went and grabbed 8192 bytes starting at each of those 11 points, and
> > > attached them.
......
> > $ xfs_db -c "sb 0" -c p -f 1099514834944.dmp2
> > <snip warnings>
> > magicnum = 0x58465342
> > blocksize = 4096
> > dblocks = 3375866880
> > rblocks = 0
> > rextents = 0
> > uuid = e36d4151-2bf0-4f0e-87e2-c21963022640
> > logstart = 1073741828
> > rootino = 128
> > rbmino = 129
> > rsumino = 130
> > rextsize = 1
> > agblocks = 268435455
....
> > blocklog = 12
....
> > So I now know that there are only 13 AGs (0-12), and you are only
> > missing 0, 2 and 8, and that the log starts at 4398046527490 which
> > matches with the chunk that I though was a log record. The AGFs
> > indicate the sequence numbers are in the correct order and match the
> > offsets, so AFAICT you've assembled the array in the right order.
> >
> > I think the best thing you could do copy the first 512 bytes from
> > the 1099514834944.dmp2 to the first sector of the device you dumped
> > this from (i.e. offset zero), and then running xfs_repair -n on it
> > to see whether it validates it as correct. (save the sector contents
> > first, jsut in case).
> >
> > root@jarvis:~/dump1# dd if=1099514834944.dmp2 of=/dev/md1 bs=512 count=1
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 0.0649365 s, 7.9 kB/s
> root@jarvis:~/dump1# xfs_i
> xfs_info  xfs_io
> root@jarvis:~/dump1# xfs_repair -n /dev/md1
> Phase 1 - find and verify superblock...
> couldn't verify primary superblock - not enough secondary superblocks with
> matching geometry !!!

Which means it found less than 13/2 = 6 valid secondary superblocks.

I should have looked at this previously: the addresses of the
secondary superblocks should be:

$ for i in `seq 0 1 12`; do echo $((i * 268435455 << 12)) ; done
0
1099511623680
2199023247360
3298534871040
4398046494720
5497558118400
6597069742080
7696581365760
8796092989440
9895604613120
10995116236800
12094627860480
13194139484160

and the offsets with superblocks in them are:

1099514834944.dmp2
3298535133184.dmp2
4398047346688.dmp2
5497559560192.dmp2
6597069676544.dmp2
7696579268608.dmp2
9895606972416.dmp2
10995117088768.dmp2
12094629761024.dmp2
13194139877376.dmp2

All wrong. The difference is between AG 1 is 3,211,264 bytes, Ag 3
is 262144 bytes, AG 4 is 851,968 bytes, and so on. There is no
consistency in the difference between where you found the headers
and where they should. There's no way I can put this back together
into a repairable filesystem...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs