On 2018/05/21 10:36, Dave Chinner wrote:
On Sat, May 19, 2018 at 12:32:24PM +0800, Xiao Yang wrote:
xfs/132 and xfs/133 running together got the following error:
------------------------------------------------------------
...
xfs/132 1s ... 1s
xfs/133 1s ... [failed, exit status 1] - output mismatch (see /var/lib/xfstests/results//xfs/133.out.bad)
...
QA output created by 133
-Format and mount
-Corrupt filesystem
-Remount, try to append
-Write did not succeed (ok).
+SCRATCH_DEV=/dev/sda11 is mounted but not on SCRATCH_MNT=common/config: - aborting
+Already mounted result:
+/dev/sda11 /mnt/xfstests/scratch
...
------------------------------------------------------------
xfs/132 led to XFS shutdown due to the corrupted inode, but it didn't rectify XFS
by umount scratch device.
AFAIK, we don't have to unmount the scratch device when a test
finishes - the test harness is supposed to do that and make sure
that it is in the correct state for the next test to run.
It seems that somewhere along the line this got broken. - I'm
guessing the fact that this test also says "don't check the scratch
device" the test harness is failing to unmount it because it's not
running _check_scratch_device. I'm guessing that it should at least
run _scratch_unmount....
Hi Dave,
Could we just make the test harness call _scratch_unmount after running every test, as below:
--------------------------------------------------------------
diff --git a/check b/check
index 96198ac..63ece67 100755
--- a/check
+++ b/check
@@ -815,6 +815,7 @@ for section in $HOST_OPTIONS_SECTIONS; do
_make_testcase_report "$tc_status"
fi
seq="after_$seqnum"
+ _scratch_unmount 2> /dev/null
done
sect_stop=`_wallclock`
interrupt=false
@@ -823,7 +824,6 @@ for section in $HOST_OPTIONS_SECTIONS; do
echo
_test_unmount 2> /dev/null
- _scratch_unmount 2> /dev/null
done
interrupt=false
---------------------------------------------------------------
Thanks,
Xiao Yang
Cheers,
Dave.
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
