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@xxxxxxxxxxxxx> 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). I'd say that there's probably only a small chance of recovering much, there's a very good chance that you'll have to resort to tools like xfs_irecover to find lost inodes on the disk to be able to recover data. Still, one step at a time... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
