diff options
author | 2025-04-23 11:43:48 +0900 | |
---|---|---|
committer | 2025-05-15 14:30:53 +0200 | |
commit | f92ee31e031c7819126d2febdda0c3e91f5d2eb9 (patch) | |
tree | 28db824b6dfbe3fa6f95536c570878226ba0d32f /tools/perf/scripts/python/export-to-postgresql.py | |
parent | btrfs: add space_info parameter for block group creation (diff) | |
download | linux-rng-f92ee31e031c7819126d2febdda0c3e91f5d2eb9.tar.xz linux-rng-f92ee31e031c7819126d2febdda0c3e91f5d2eb9.zip |
btrfs: introduce btrfs_space_info sub-group
Current code assumes we have only one space_info for each block group type
(DATA, METADATA, and SYSTEM). We sometime need multiple space infos to
manage special block groups.
One example is handling the data relocation block group for the zoned mode.
That block group is dedicated for writing relocated data and we cannot
allocate any regular extent from that block group, which is implemented in
the zoned extent allocator. This block group still belongs to the normal
data space_info. So, when all the normal data block groups are full and
there is some free space in the dedicated block group, the space_info
looks to have some free space, while it cannot allocate normal extent
anymore. That results in a strange ENOSPC error. We need to have a
space_info for the relocation data block group to represent the situation
properly.
Adds a basic infrastructure for having a "sub-group" of a space_info:
creation and removing. A sub-group space_info belongs to one of the
primary space_infos and has the same flags as its parent.
This commit first introduces the relocation data sub-space_info, and the
next commit will introduce tree-log sub-space_info. In the future, it could
be useful to implement tiered storage for btrfs e.g. by implementing a
sub-group space_info for block groups resides on a fast storage.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions