From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH] fstests: btrfs/301: handle auto-removed qgroups
Date: Tue, 7 May 2024 16:36:06 +0930 [thread overview]
Message-ID: <20240507070606.64126-1-wqu@suse.com> (raw)
There are always attempts to auto-remove empty qgroups after dropping a
subvolume.
For squota mode, not all qgroups can or should be dropped, as there are
common cases where the dropped subvolume are still referred by other
snapshots.
In that case, the numbers can only be freed when the last referencer
got dropped.
The latest kernel attempt would only try to drop empty qgroups for
squota mode.
But even with such safe change, the test case still needs to handle
auto-removed qgroups, by explicitly echoing "0", or later calculation
would break bash grammar.
This patch would add extra handling for such removed qgroups, to be
future proof for qgroup auto-removal behavior change.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
tests/btrfs/301 | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/tests/btrfs/301 b/tests/btrfs/301
index db469724..bb18ab04 100755
--- a/tests/btrfs/301
+++ b/tests/btrfs/301
@@ -51,9 +51,17 @@ _require_fio $fio_config
get_qgroup_usage()
{
local qgroupid=$1
+ local output
- $BTRFS_UTIL_PROG qgroup show --sync --raw $SCRATCH_MNT | \
- grep "$qgroupid" | $AWK_PROG '{print $3}'
+ output=$($BTRFS_UTIL_PROG qgroup show --sync --raw $SCRATCH_MNT | \
+ grep "$qgroupid" | $AWK_PROG '{print $3}')
+ # The qgroup is auto-removed, this can only happen if its numbers are
+ # already all zeros, so here we only need to explicitly echo "0".
+ if [ -z "$output" ]; then
+ echo "0"
+ else
+ echo "$output"
+ fi
}
get_subvol_usage()
--
2.44.0
next reply other threads:[~2024-05-07 7:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 7:06 Qu Wenruo [this message]
2024-05-21 1:19 ` [PATCH] fstests: btrfs/301: handle auto-removed qgroups Boris Burkov
2024-05-23 15:43 ` Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240507070606.64126-1-wqu@suse.com \
--to=wqu@suse.com \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).