btrfs: block-group: fix free-space bitmap threshold
authorMarcos Paulo de Souza <mpdesouza@suse.com>
Fri, 21 Aug 2020 14:54:44 +0000 (11:54 -0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 9 Sep 2020 17:14:26 +0000 (19:14 +0200)
commit6b09009a2eaeebb1b30cefc7aa42688b6b05b891
treef71a5fc0cdc84265713142675590c70a919da192
parent6d12fbd0c4b7bb481f581110cd171a908317d585
btrfs: block-group: fix free-space bitmap threshold

commit e3e39c72b99f93bbd0420d38c858e7c4a061bb63 upstream.

[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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/block-group.c
fs/btrfs/free-space-tree.c