On Thu, Aug 20, 2015 at 01:08:27PM -0500, Eric Sandeen wrote:
> libxfs_umount was failing to free a handful of resources; fix that up.
> Call it from xfs_copy as well, while we're at it; every other libxfs_mount
> has a libxfs_umount counterpart, at least on a clean exit.
xfs/077 6s ... - output mismatch (see /home/dave/src/xfstests-dev/results//xfs/077.out.bad)
--- tests/xfs/077.out 2015-08-05 15:00:15.000000000 +1000
+++ /home/dave/src/xfstests-dev/results//xfs/077.out.bad 2015-08-24 11:35:42.000000000 +1000
@@ -18,4 +18,6 @@
writing all SBs
new UUID = <EXACTUUID>
== xfs_copy with new UUID
+cache_purge: shake on cache 0x64b2e0 left 1 nodes!?
== xfs_copy with duplicate UUID
+cache_purge: shake on cache 0x64b2e0 left 1 nodes!?
...
It would seem that this exposes a buffer refcount issue in xfs_copy?
Oh, yeah, the superblock. Patch modified to include this hunk:
@@ -696,6 +696,7 @@ main(int argc, char **argv)
sbp = libxfs_readbuf(mbuf.m_ddev_targp, XFS_SB_DADDR,
1 << (sb->sb_sectlog - BBSHIFT),
0, &xfs_sb_buf_ops);
+ libxfs_putbuf(sbp);
mp = libxfs_mount(&mbuf, sb, xargs.ddev, xargs.logdev, xargs.rtdev, 0);
if (mp == NULL) {
Which makes the immediate problem go away.
Eric, can you send another patch here to abort xfs_copy if the
superblock is detected as corrupt by the verifier?
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
