On 2/27/13 10:28 AM, Jason Detring wrote:
> find-502  207.983594: xfs_da_btree_corrupt: dev 7:0 bno
> 0x5a4f8 nblks 0x8 hold 1 pincount 0 lock 0 flags DONE|PAGES caller
Was this on the same image as you sent earlier?
Ok, so this tells us that it was trying to read sector nr. 0x5a4f8 (369912), or
What's really on disk there?
$ xfs_db problemimage.xfs
xfs_db> blockget -n
xfs_db> daddr 369912
block 49152 (3/0) type sb
xfs_db> type text
000: 58 46 53 42 00 00 10 00 00 00 00 00 00 00 f0 d3 XFSB............
So it really did have a superblock location that it was reading
at that point - the backup SB in the 3rd allocation group, to be exact.
But it shouldn't have been trying to read a superblock at this point
in the code...
Hm, maybe I should have had you enable all xfs tracepoints to get
more info about where we thought we were on disk when we were doing this.
If you used trace-cmd you can do "trace-cmd record -e xfs*" IIRC.
You can do similar echo 1 > /<blah>/xfs*/enable I think for the sysfs route.
Can you identify which directory it was that tripped the above error?
(I still think it sounds like a miscompile, but trying to get more clues)