btrfs/179: call sync qgroup counts
authorAnand Jain <anand.jain@oracle.com>
Wed, 12 Feb 2020 09:35:09 +0000 (17:35 +0800)
committerEryu Guan <guaneryu@gmail.com>
Mon, 17 Feb 2020 13:16:14 +0000 (21:16 +0800)
On some systems btrfs/179 fails because the check finds that there
is difference in the qgroup counts.

So as the intention of the test case is to test any hang like
situation during heavy snapshot create/delete operation with quota
enabled, so make sure the qgroup counts are consistent at the end of
the test case, so to make the check happy.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Qu Wenruo <quwenruo.btrfs@gmx.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
tests/btrfs/179

index 4a24ea419a7e3a353ba5fe39be304775ed705658..8795d59c01f86f4e3225c9d3b8a668b48cae81d5 100755 (executable)
@@ -109,6 +109,15 @@ wait $snapshot_pid
 kill $delete_pid
 wait $delete_pid
 
+# By the async nature of qgroup tree scan and subvolume delete, the latest
+# qgroup counts at the time of umount might not be upto date, if it isn't
+# then the check will report the difference in count. The difference in
+# qgroup counts are anyway updated in the following mount, so it is not a
+# real issue that this test case is trying to verify. So make sure the
+# qgroup counts are in sync before unmount happens.
+
+$BTRFS_UTIL_PROG subvolume sync $SCRATCH_MNT >> $seqres.full
+
 # success, all done
 echo "Silence is golden"