summaryrefslogtreecommitdiff
path: root/scripts/bpf_helpers_doc.py
diff options
context:
space:
mode:
authorMarcos Paulo de Souza <mpdesouza@suse.com>2020-08-21 11:54:44 -0300
committerDavid Sterba <dsterba@suse.com>2020-08-27 13:37:54 +0200
commite3e39c72b99f93bbd0420d38c858e7c4a061bb63 (patch)
treecf500248ff53d9145c4a7f752720cdd3cc863a3d /scripts/bpf_helpers_doc.py
parenta84d5d429f9eb56f81b388609841ed993f0ddfca (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