<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 9, 2012 at 2:48 AM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, Nov 08, 2012 at 11:28:20PM -0800, Aaron Goulding wrote:<br>
> On Thu, Nov 8, 2012 at 1:02 PM, Dave Chinner <<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>> wrote:<br>
><br>
> > That seems like way too many to be filesystem metadata hits. I woul<br>
> > dhave expected the same number of hits as there are AGs in the<br>
> > filesytem. What you want is the XFSB string in the first 4<br>
> > bytes of a sector, with the next sector having XAGF as the first<br>
> > four bytes....<br>
> ><br>
><br>
> Okay this proved helpful. I ran a check of the first 1024 bytes at each of<br>
> those 19000 results for XAGF, then limited that to results that occurred at<br>
> the 512 byte relative mark. This dropped the results down to 11. I then<br>
> went and grabbed 8192 bytes starting at each of those 11 points, and<br>
> attached them.<br>
<br>
</div></div>bad:<br>
<br>
4398367673432.dmp2 - has a headr followed by zeros, then parts of a<br>
transaction headers, etc. just looks like random bits of filesystem<br>
metadata record. It's probably the log.<br>
<br>
12094629761024.dmp2 - has the first part of a superblco, but the<br>
empty part of the sb is not zeroed - looks like a utf8 string?<br>
Perhaps directory structure? components.ini.new is the repeated<br>
name... AGI, AGF AGF look intact. Has this fs been grown in the<br>
past?<br>
<br>
13194139877376.dmp2 - Looks like an empty, pristine AG just freshly<br>
allocated by mkfs. (AGFL contains only blocks 4,5,6 and 7, and the<br>
AGF and ABTB block show a single large freespace extent covering the<br>
entire AG (0x937a4 blocks in size).<br>
<br>
So, judging by what I've got here, the file names are the block<br>
offset of the data and that the offsets start at 0. That gives me<br>
the headers for AGs 1, 3, 4, (the log in AG 4), 5, 6, 7, 9, 10, 11<br>
and 12. Missing are 0, 2 and 8.<br>
<br>
/me hugs xfs_db<br>
<br>
$ xfs_db -c "sb 0" -c p -f 1099514834944.dmp2<br>
<snip warnings><br>
magicnum = 0x58465342<br>
blocksize = 4096<br>
dblocks = 3375866880<br>
rblocks = 0<br>
rextents = 0<br>
uuid = e36d4151-2bf0-4f0e-87e2-c21963022640<br>
logstart = 1073741828<br>
rootino = 128<br>
rbmino = 129<br>
rsumino = 130<br>
rextsize = 1<br>
agblocks = 268435455<br>
agcount = 13<br>
rbmblocks = 0<br>
logblocks = 521728<br>
versionnum = 0xb4b4<br>
sectsize = 512<br>
inodesize = 256<br>
inopblock = 16<br>
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"<br>
blocklog = 12<br>
sectlog = 9<br>
inodelog = 8<br>
inopblog = 4<br>
agblklog = 28<br>
rextslog = 0<br>
inprogress = 0<br>
imax_pct = 5<br>
icount = 3970688<br>
ifree = 11<br>
fdblocks = 260163907<br>
frextents = 0<br>
uquotino = 0<br>
gquotino = 0<br>
qflags = 0<br>
flags = 0<br>
shared_vn = 0<br>
inoalignmt = 2<br>
unit = 0<br>
width = 0<br>
dirblklog = 0<br>
logsectlog = 0<br>
logsectsize = 0<br>
logsunit = 1<br>
features2 = 0xa<br>
bad_features2 = 0xa<br>
<br>
So I now know that there are only 13 AGs (0-12), and you are only<br>
missing 0, 2 and 8, and that the log starts at 4398046527490 which<br>
matches with the chunk that I though was a log record. The AGFs<br>
indicate the sequence numbers are in the correct order and match the<br>
offsets, so AFAICT you've assembled the array in the right order.<br>
<br>
I think the best thing you could do copy the first 512 bytes from<br>
the 1099514834944.dmp2 to the first sector of the device you dumped<br>
this from (i.e. offset zero), and then running xfs_repair -n on it<br>
to see whether it validates it as correct. (save the sector contents<br>
first, jsut in case).<br>
<br></blockquote><div>root@jarvis:~/dump1# dd if=1099514834944.dmp2 of=/dev/md1 bs=512 count=1<br>1+0 records in<br>1+0 records out<br>512 bytes (512 B) copied, 0.0649365 s, 7.9 kB/s<br>root@jarvis:~/dump1# xfs_i<br>xfs_info xfs_io<br>
root@jarvis:~/dump1# xfs_repair -n /dev/md1<br>Phase 1 - find and verify superblock...<br>couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!!<br><br>attempting to find secondary superblock...<br>
......................................................................................................................<br><br>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.<br>
</div></div><br>-Aaron<br></div>