linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC 0/4] btrfs: qgroup: rescan enhancement related to INCONSISTENT flag
Date: Sun, 22 Aug 2021 15:01:56 +0800	[thread overview]
Message-ID: <20210822070200.36953-1-wqu@suse.com> (raw)

There is a long existing window that if we did some operations marking
qgroup INCONSISTENT during a qgroup rescan, the INCONSISTENT bit will be
cleared by rescan, leaving incorrect qgroup numbers unnoticed.

Furthermore, when we mark qgroup INCONSISTENT, we can in theory skip all
qgroup accountings.
Since the numbers are already crazy, we don't really need to waste time
updating something that's already wrong.

So here we introduce two runtime flags:

- BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN
  To inform any running rescan to exit immediately and don't clear
  the INCONSISTENT bit on its exit.

- BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING
  To inform qgroup code not to do any accounting for dirty extents.

  But still allow operations on qgroup relationship to be continued.

Both flags will be set when an operation marks the qgroup INCONSISTENT
and only get cleared when a new rescan is started.


With those flags, we can have the following enhancement:

- Prevent qgroup rescan to clear inconsistent flag which should be kept
  If an operation marks qgroup inconsistent when a rescan is running,
  qgroup rescan will clear the inconsistent flag while the qgroup
  numbers are already wrong.

- Skip qgroup accountings while qgroup numbers are already inconsistent

- Skip huge subtree accounting when dropping subvolumes
  With the obvious cost of marking qgroup inconsistent


Reason for RFC:
- If the runtime qgroup flags are acceptable

- If the behavior of marking qgroup inconsistent when dropping large
  subvolumes

- If the lifespan of runtime qgroup flags are acceptable
  They have longer than needed lifespan (from inconsistent time point to
  next rescan), not sure if it's OK.

Qu Wenruo (4):
  btrfs: introduce BTRFS_QGROUP_STATUS_FLAGS_MASK for later expansion
  btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN
  btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip
    qgroup accounting
  btrfs: skip subtree scan if it's too high to avoid low stall in
    btrfs_commit_transaction()

 fs/btrfs/qgroup.c               | 82 ++++++++++++++++++++++++---------
 fs/btrfs/qgroup.h               |  3 ++
 include/uapi/linux/btrfs_tree.h |  4 ++
 3 files changed, 67 insertions(+), 22 deletions(-)

-- 
2.32.0


             reply	other threads:[~2021-08-22  7:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-22  7:01 Qu Wenruo [this message]
2021-08-22  7:01 ` [PATCH RFC 1/4] btrfs: introduce BTRFS_QGROUP_STATUS_FLAGS_MASK for later expansion Qu Wenruo
2021-08-22  7:01 ` [PATCH RFC 2/4] btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN Qu Wenruo
2021-08-22  7:01 ` [PATCH RFC 3/4] btrfs: introduce BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING to skip qgroup accounting Qu Wenruo
2021-08-22  7:02 ` [PATCH RFC 4/4] btrfs: skip subtree scan if it's too high to avoid low stall in btrfs_commit_transaction() Qu Wenruo
2021-08-23 17:24 ` [PATCH RFC 0/4] btrfs: qgroup: rescan enhancement related to INCONSISTENT flag David Sterba
2021-08-23 23:27   ` Qu Wenruo
2021-08-23 17:30 ` David Sterba
2021-08-24  6:54   ` Qu Wenruo
2021-08-24  7:49     ` 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=20210822070200.36953-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).