[PATCH] btrfs/228: sync filesystem after creating subvolume

[fdmanana@kernel.org]

From: Filipe Manana <fdmanana@suse.com>

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>
---
 tests/btrfs/228 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/tests/btrfs/228 b/tests/btrfs/228
index fde623fc..5ef1dfd7 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"
 
-- 
2.35.1