From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: qgroup: Pause and resume qgroup for subvolume removal
Date: Tue, 6 Aug 2019 13:35:32 +0800 [thread overview]
Message-ID: <20190806053535.14375-1-wqu@suse.com> (raw)
Btrfs qgroup has one big performance overhead for certain snapshot drop.
Current btrfs_drop_snapshot() will try its best to find the highest
shared node, and just drop one ref of that common node.
This behavior is good for minimize extent tree modification, but a
disaster for qgroup.
Example:
Root 300 Root 301
A B
| \ / |
| X |
| / \ |
C D
/ \ / \
E F G H
/ \ / \ / \ / \
I J K L M N O P
In above case, if we're dropping root 301, btrfs_drop_snapshot() will
only drop one ref for tree block C and D.
But for qgroup, tree blocks E~P also have their owner changed, from
300, 301 to 300 only.
Currently we use btrfs_qgroup_trace_subtree() to manually re-dirty tree
block E~P. And since such ref change happens in one transaction for each
ref drop, we can't split the overhead to different transactions.
This could cause qgroup extent record flood, hugely damage performance
or even cause OOM for too many qgroup extent records.
Unfortunately unlike previous qgroup + balance optimization, we can't
really do much to help.
So to make the problem less obvious, let's just pause qgroup and resume
it for snapshot drop, and queue a rescan automatically.
For independent subvolume or small snapshot, we don't really need to do
such pause/rescan workaround, as regular per-tree-block dropping is
pretty qgroup friendly.
One existing test case, btrfs/179 can trigger the behavior and test the
patchset. Although this patchset will change the snapshot drop behavior,
thus leaving the test harder to detect the original detect lock.
Changelog:
v1:
- Prevent race between quota enable/disable and quota pause/resume
Qu Wenruo (3):
btrfs: Refactor btrfs_clean_one_deleted_snapshot() to use fs_info
other than root
btrfs: qgroup: Introduce quota pause infrastrucutre
btrfs: Pause and resume qgroup for snapshot drop
fs/btrfs/ctree.h | 3 +-
fs/btrfs/disk-io.c | 9 +++--
fs/btrfs/extent-tree.c | 13 ++++++-
fs/btrfs/qgroup.c | 87 +++++++++++++++++++++++++++++++++++++++++-
fs/btrfs/qgroup.h | 3 ++
fs/btrfs/relocation.c | 4 +-
fs/btrfs/transaction.c | 8 ++--
fs/btrfs/transaction.h | 2 +-
8 files changed, 114 insertions(+), 15 deletions(-)
--
2.22.0
next reply other threads:[~2019-08-06 5:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 5:35 Qu Wenruo [this message]
2019-08-06 5:35 ` [PATCH 1/3] btrfs: Refactor btrfs_clean_one_deleted_snapshot() to use fs_info other than root Qu Wenruo
2019-08-06 5:35 ` [PATCH 2/3] btrfs: qgroup: Introduce quota pause infrastrucutre Qu Wenruo
2019-08-06 5:35 ` [PATCH 3/3] btrfs: Pause and resume qgroup for snapshot drop 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=20190806053535.14375-1-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).