* [PATCH] btrfs/228: sync filesystem after creating subvolume
@ 2023-05-10 10:55 fdmanana
2023-05-10 12:22 ` Anand Jain
2023-05-11 0:55 ` Qu Wenruo
0 siblings, 2 replies; 3+ messages in thread
From: fdmanana @ 2023-05-10 10:55 UTC (permalink / raw)
To: fstests; +Cc: linux-btrfs, Filipe Manana
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs/228: sync filesystem after creating subvolume
2023-05-10 10:55 [PATCH] btrfs/228: sync filesystem after creating subvolume fdmanana
@ 2023-05-10 12:22 ` Anand Jain
2023-05-11 0:55 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Anand Jain @ 2023-05-10 12:22 UTC (permalink / raw)
To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana
> +# 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs/228: sync filesystem after creating subvolume
2023-05-10 10:55 [PATCH] btrfs/228: sync filesystem after creating subvolume fdmanana
2023-05-10 12:22 ` Anand Jain
@ 2023-05-11 0:55 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2023-05-11 0:55 UTC (permalink / raw)
To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana
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"
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-05-11 0:56 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-10 10:55 [PATCH] btrfs/228: sync filesystem after creating subvolume fdmanana
2023-05-10 12:22 ` Anand Jain
2023-05-11 0:55 ` Qu Wenruo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox