From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/2] btrfs: qgroup: stale qgroups related impromvents
Date: Tue, 7 May 2024 16:28:09 +0930 [thread overview]
Message-ID: <cover.1715064550.git.wqu@suse.com> (raw)
[CHANGELOG]
v3:
- Do not allow dropping non-zero qgroups for squota
Due to the design of squota, a fully dropped subvolume can still have
non-zero qgroups, as in the extent tree the delta is still using the
original owner (the dropped subvolume).
So we can not drop any non-zero squota qgroups
- Slight change on the can_delete_qgroup() condition
To co-operate with above change.
v2:
- Do more sanity checks before deleting a qgroup
- Make squota to handle auto deleted qgroup more gracefully
Unfortunately the behavior change would affect btrfs/301, as the
fully deleted subvolume would make the test case to cause bash grammar
error (since the qgroup is gone with the subvolume).
Cc Boris for extra comments on squota compatibility and future
btrfs/311 updates ideas.
We have two problems in recent qgroup code:
- One can not delete a fully removed qgroup if the drop hits
drop_subtree_threshold
As hitting drop_subtree_threshold would mark qgroup inconsistent and
skip all accounting, this would leave qgroup number untouched (thus
non-zero), and btrfs refuses to delete qgroup with non-zero rfer/excl
numbers.
This would be addressed by the first patch, allowing qgroup
deletion as long as it doesn't have any child nor a corresponding
subvolume.
- Deleted snapshot would leave a stale qgroup
This is a long existing problem.
Although previous pushes all failed, just let me try it again.
The idea is commit current transaction if needed (full accounting mode
and qgroup numbers are consistent), then try to remove the subvolume
qgroup after it is fully dropped.
For full qgroup mode, no matter if qgroup is inconsistent, we will
auto remove the dropped 0 level qgroup.
(If consistent, the qgroup numbers should all be 0, and a safe
removal. If inconsistent, we still remove the qgroup, leaving
higher level qgroup incorrect, but since it's already inconsistent,
we need a rescan anyway).
For squota mode, we only do the auto reap if the qgroup numbers are
already 0.
Otherwise the qgroup numbers would be needed for future accounting.
The behavior change would only affect btrfs/301, which still expects the
dropped subvolume would still leave its qgroup untouched.
But that can be easily fixed by explicitly echoing "0" for dropped
subvolume.
Qu Wenruo (2):
btrfs: slightly loose the requirement for qgroup removal
btrfs: automatically remove the subvolume qgroup
fs/btrfs/extent-tree.c | 8 +++
fs/btrfs/qgroup.c | 120 ++++++++++++++++++++++++++++++++++++++---
fs/btrfs/qgroup.h | 2 +
3 files changed, 123 insertions(+), 7 deletions(-)
--
2.45.0
next reply other threads:[~2024-05-07 6:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 6:58 Qu Wenruo [this message]
2024-05-07 6:58 ` [PATCH v3 1/2] btrfs: slightly loose the requirement for qgroup removal Qu Wenruo
2024-05-20 22:46 ` Boris Burkov
2024-05-07 6:58 ` [PATCH v3 2/2] btrfs: automatically remove the subvolume qgroup Qu Wenruo
2024-05-20 22:50 ` Boris Burkov
2024-05-20 23:03 ` Qu Wenruo
2024-05-21 1:05 ` Qu Wenruo
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=cover.1715064550.git.wqu@suse.com \
--to=wqu@suse.com \
--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 NNTP newsgroup(s).