This patchset will separate original qgroup->reserved into a new
structure, btrfs_qgroup_rsv, which has different reservation for
different types.
Currently it will only includes data and meta type.
The main advantage is:
1) Better underflow detection
Now it can detection which reservation type is causing the underflow.
2) Easier to expend
All interface is updated to access reservation type, it will get
super easy to be expended, especially for later delalloc reservation.
3) Better encapsulation
No longer need to manually trace underflow or add trace events, all
encapsulated into 2 functions.
Despite of the qgroup reservation refactor, also fix a bug where qgroup
relationship update modifies parent qgroup reservation wrongly.
Although I tend to agree with Jeff's idea to remove support of
multi-level qgroup, at least fix what I exposed during coding.
Changelog:
v2:
Use _MAX naming, as _TYPES naming reusing the last type makes it quite
easier to screw up space allocation, since we need +1 to handle
_TYPES. Suggested by Nikolay, Edmund, Jeff and already experienced
such problem by myself.
Rename the qgroup_rsv_increase/decrease() to qgroup_rsv_add/release(),
to follow the block_rsv API, suggested by Nikolay, Jeff and Edmund.
Better description for the bug in __qgroup_excl_accounting(),
suggested by Nikolay.
Qu Wenruo (6):
btrfs: qgroup: Skeleton to support separate qgroup reservation type
btrfs: qgroup: Introduce helpers to update and access new qgroup rsv
btrfs: qgroup: Make qgroup_reserve and its callers to use separate
reservation type
btrfs: qgroup: Fix wrong qgroup reservation update for relationship
modification
btrfs: qgroup: Update trace events to use new separate rsv types
btrfs: qgroup: Cleanup the remaining old reservation counters
fs/btrfs/qgroup.c | 169 ++++++++++++++++++++++++++++++-------------
fs/btrfs/qgroup.h | 28 ++++++-
include/trace/events/btrfs.h | 17 +++--
3 files changed, 154 insertions(+), 60 deletions(-)
--
2.14.2
--
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
