On 2/11/14, 1:55 PM, Cody P Schafer wrote:
> xfsprogs version: v3.2.0-alpha2-14-g6e79202
>
> uname: Linux hostname 3.11.10-301.fc20.ppc64 #1 SMP Tue Dec 10 00:35:15 MST 2013 ppc64 POWER8 (architected), altivec supported CHRP IBM,8286-42A GNU/Linux
>
> full log attached.
Yikes, that's one destroyed filesystem. What happened?
==6700== Invalid read of size 8
==6700== at 0x1003DB10: libxfs_trans_commit (trans.c:743)
==6700== by 0x10028F9B: mv_orphanage (phase6.c:1222)
==6700== by 0x1002A627: phase6 (phase6.c:2970)
==6700== by 0x1000490F: main (xfs_repair.c:779)
So it's reading ip:
if (ip->i_itemp) <--- read here, line 743
kmem_zone_free(xfs_ili_zone, ip->i_itemp);
==6700== Address 0x13cbf4b8 is 216 bytes inside a block of size 416 free'd
==6700== at 0x4067C2C: free (in /usr/lib64/valgrind/vgpreload_memcheck-ppc64-linux.so)
==6700== by 0x1003C9EF: libxfs_iput (kmem.h:41)
==6700== by 0x1003DB0B: libxfs_trans_commit (trans.c:740)
==6700== by 0x10028F9B: mv_orphanage (phase6.c:1222)
==6700== by 0x1002A627: phase6 (phase6.c:2970)
==6700== by 0x1000490F: main (xfs_repair.c:779)
after it's been previously freed
if (iip->ili_lock_flags) {
iip->ili_lock_flags = 0;
return;
} else {
libxfs_iput(ip, 0); <--- freed here, line 740
}
==6700== Invalid write of size 8
==6700== at 0x1003DB38: libxfs_trans_commit (trans.c:747)
==6700== by 0x10028F9B: mv_orphanage (phase6.c:1222)
==6700== by 0x1002A627: phase6 (phase6.c:2970)
==6700== by 0x1000490F: main (xfs_repair.c:779)
ditto for this write:
ip->i_itemp = NULL; <--- written here, line 747
So, this should be fixed, but I kind of doubt it's the underlying
problem with your xfs_repair failure.
-Eric
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
