btrfs/228: sync filesystem after creating subvolume

Test case btrfs/228 creates a subvolume and then calls the dump-tree
command from btrfs-progs. The tree dumping accesses the device directly
and therefore can only see committed metadata - this used to work because
subvolume creation used to commit the transaction that was used to create
the subvolume, however it is no longer the case after a recent patch that
currently is only on the btrfs integration branch "misc-next". That patch
has the following subject:

   "btrfs: don't commit transaction for every subvol create"

So explicitly sync the filesystem before calling the dump-tree command,
commenting why we do it. This way the test works before and after that
patch, for any kernel release.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Zorro Lang <zlang@kernel.org>

1 files changed, 5 insertions, 0 deletions

diff --git a/tests/btrfs/228 b/tests/btrfs/228
index fde623fcc6..5ef1dfd741 100755
--- a/tests/btrfs/228
+++ b/tests/btrfs/228
@@ -28,6 +28,11 @@ _scratch_mount
 $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/newvol >> $seqres.full 2>&1 \
 	|| _fail "couldn't create subvol"
 
+# Subvolume creation used to commit the transaction used to create it, but after
+# the patch "btrfs: don't commit transaction for every subvol create", that
+# changed, so sync the fs to commit any open transaction.
+$BTRFS_UTIL_PROG filesystem sync $SCRATCH_MNT
+
 $BTRFS_UTIL_PROG inspect-internal dump-tree -t1 $SCRATCH_DEV \
 	| grep -q "256 ROOT_ITEM"  ||	_fail "First subvol with id 256 doesn't exist"