XFS filesystem recovery from secondary superblocks

[Aaron Goulding]

On Fri, Nov 9, 2012 at 2:48 AM, Dave Chinner <david at 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 at 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.
>
> bad:
>
> 4398367673432.dmp2 - has a headr followed by zeros, then parts of a
> transaction headers, etc. just looks like random bits of filesystem
> metadata record. It's probably the log.
>
> 12094629761024.dmp2 - has the first part of a superblco, but the
> empty part of the sb is not zeroed - looks like a utf8 string?
> Perhaps directory structure? components.ini.new is the repeated
> name... AGI, AGF AGF look intact. Has this fs been grown in the
> past?
>
> 13194139877376.dmp2 - Looks like an empty, pristine AG just freshly
> allocated by mkfs. (AGFL contains only blocks 4,5,6 and 7, and the
> AGF and ABTB block show a single large freespace extent covering the
> entire AG (0x937a4 blocks in size).
>
> So, judging by what I've got here, the file names are the block
> offset of the data and that the offsets start at 0. That gives me
> the headers for AGs 1, 3, 4, (the log in AG 4), 5, 6, 7, 9, 10, 11
> and 12. Missing are 0, 2 and 8.
>
> /me hugs xfs_db
>
> $ 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
> agcount = 13
> rbmblocks = 0
> logblocks = 521728
> versionnum = 0xb4b4
> sectsize = 512
> inodesize = 256
> inopblock = 16
> fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
> blocklog = 12
> sectlog = 9
> inodelog = 8
> inopblog = 4
> agblklog = 28
> rextslog = 0
> inprogress = 0
> imax_pct = 5
> icount = 3970688
> ifree = 11
> fdblocks = 260163907
> frextents = 0
> uquotino = 0
> gquotino = 0
> qflags = 0
> flags = 0
> shared_vn = 0
> inoalignmt = 2
> unit = 0
> width = 0
> dirblklog = 0
> logsectlog = 0
> logsectsize = 0
> logsunit = 1
> features2 = 0xa
> bad_features2 = 0xa
>
> 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 at 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 at jarvis:~/dump1# xfs_i
xfs_info  xfs_io
root at 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 !!!

attempting to find secondary superblock...
......................................................................................................................

Hrm I'm guessing that's not a good response, but I'll let it run. If that
doesn't return good results, I'll try xfs_irecover.

-Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20121109/65dd641e/attachment.htm>