diff options
author | Marcos Paulo de Souza <mpdesouza@suse.com> | 2020-08-21 11:54:44 -0300 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2020-08-27 13:37:54 +0200 |
commit | e3e39c72b99f93bbd0420d38c858e7c4a061bb63 (patch) | |
tree | cf500248ff53d9145c4a7f752720cdd3cc863a3d /scripts/bpf_helpers_doc.py | |
parent | a84d5d429f9eb56f81b388609841ed993f0ddfca (diff) |
btrfs: block-group: fix free-space bitmap threshold
[BUG]
After commit 9afc66498a0b ("btrfs: block-group: refactor how we read one
block group item"), cache->length is being assigned after calling
btrfs_create_block_group_cache. This causes a problem since
set_free_space_tree_thresholds calculates the free-space threshold to
decide if the free-space tree should convert from extents to bitmaps.
The current code calls set_free_space_tree_thresholds with cache->length
being 0, which then makes cache->bitmap_high_thresh zero. This implies
the system will always use bitmap instead of extents, which is not
desired if the block group is not fragmented.
This behavior can be seen by a test that expects to repair systems
with FREE_SPACE_EXTENT and FREE_SPACE_BITMAP, but the current code only
created FREE_SPACE_BITMAP.
[FIX]
Call set_free_space_tree_thresholds after setting cache->length. There
is now a WARN_ON in set_free_space_tree_thresholds to help preventing
the same mistake to happen again in the future.
Link: https://github.com/kdave/btrfs-progs/issues/251
Fixes: 9afc66498a0b ("btrfs: block-group: refactor how we read one block group item")
CC: stable@vger.kernel.org # 5.8+
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'scripts/bpf_helpers_doc.py')
0 files changed, 0 insertions, 0 deletions