[PATCH 0/2] btrfs: qgroup: stale qgroups related impromvents

[Qu Wenruo <wqu@suse.com>]

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, to allowing qgroup
  deletion as long as it doesn't have any child nor a corresponding
  subvolume.

- Deleted subvolumes leaves a stale qgroup until next rescan
  This is a long existing problem.

  Although previous pushes all failed, just let me try it again.

  The idea is commit current transaction (to sync qgroup numbers), then
  try to remove the subvolume qgroup if it's fully dropped.

Qu Wenruo (2):
  btrfs: slightly loose the requirement for qgroup removal
  btrfs: automatically remove the subvolume qgroup

 fs/btrfs/extent-tree.c |  9 +++++
 fs/btrfs/qgroup.c      | 76 ++++++++++++++++++++++++++++++++++++++----
 fs/btrfs/qgroup.h      |  2 ++
 3 files changed, 80 insertions(+), 7 deletions(-)

-- 
2.44.0