The patchset does the following things:
1) Enhance comment for qgroup, rename 2 functions
Explain the how qgroup works, so new developers won't waste too much
time digging into the boring codes.
The qgroup work flow is split into 3 main phrases:
Reverse, Trace, Account.
And rename functions like btrfs_qgroup_insert_dirty_extent_record()
to btrfs_qgroup_trace_extent(), to follow the "Trace" phrase.
Other function name already follows such schema before.
2) Move account_shared_subtree() and account_leaf_items() to qgroup.c
Such functions are only used by qgroup, so move them to qgroup.c and
rename them to follow "trace" schema.
3) Fix the long standing qgroup balance corruption
Commit 62b99540a1d91e4 doesn't fix the problem completely.
It can only handle case that merge_reloc_roots() are all done in one
If transaction commits during merge_reloc_roots(), the data extents
will leak again.
The tree fix is to info qgroup to trace both subtree(tree reloc tree
and destination fs tree), at replace_path() time.
Inside replace_path(), there is one transaction start and end, so we
must make qgroup to trace both subtrees.
Thanks for previous work, now we can easily trace subtree, so the fix
is quite simple now.
And the cause also makes it easier to create pinpoint test case for
Qu Wenruo (4):
btrfs: qgroup: Add comments explaining how btrfs qgroup works
btrfs: qgroup: Rename functions to make it follow
btrfs: Expoert and move leaf/subtree qgroup helpers to qgroup.c
btrfs: qgroup: Fix qgroup data leaking by using subtree tracing
fs/btrfs/delayed-ref.c | 2 +-
fs/btrfs/extent-tree.c | 220 +------------------------------------------
fs/btrfs/qgroup.c | 219 +++++++++++++++++++++++++++++++++++++++++-
fs/btrfs/qgroup.h | 64 +++++++++++--
fs/btrfs/relocation.c | 119 +++++------------------
fs/btrfs/tree-log.c | 2 +-
include/trace/events/btrfs.h | 2 +-
7 files changed, 302 insertions(+), 326 deletions(-)
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html