diff mbox series

btrfs/228: sync filesystem after creating subvolume

Message ID 6553d98ab74fe2fd627749f368d9623a0b12ee4f.1683716041.git.fdmanana@suse.com (mailing list archive)
State New, archived
Headers show
Series btrfs/228: sync filesystem after creating subvolume | expand

Commit Message

Filipe Manana May 10, 2023, 10:55 a.m. UTC
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(+)

Comments

Anand Jain May 10, 2023, 12:22 p.m. UTC | #1
> +# 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"
>   

Oh yes. Nice catch.

Reviewed-by: Anand Jain <anand.jain@oracle.com>

Thanks
Qu Wenruo May 11, 2023, 12:55 a.m. UTC | #2
On 2023/5/10 18:55, fdmanana@kernel.org wrote:
> 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>

Reviewed-by: Qu Wenruo <wqu@suse.com>

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"
>
diff mbox series

Patch

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"