On 2023/5/10 18:55, fdmanana@xxxxxxxxxx wrote:
From: Filipe Manana <fdmanana@xxxxxxxx>
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@xxxxxxxx>
Reviewed-by: Qu Wenruo <wqu@xxxxxxxx>
Thanks,
Qu
---
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"
