]> git.baikalelectronics.ru Git - kernel.git/commit
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)
committerDavid Sterba <dsterba@suse.com>
Thu, 27 Aug 2020 11:37:54 +0000 (13:37 +0200)
commitc9825c43e9d7f5f382389ff7d71befd1f0c728cd
treecf500248ff53d9145c4a7f752720cdd3cc863a3d
parentbc2268abacfd3eb02fa16be0e140884f2a79e151
btrfs: block-group: fix free-space bitmap threshold

[BUG]
After commit 013d5599d58a ("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: 013d5599d58a ("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>
fs/btrfs/block-group.c
fs/btrfs/free-space-tree.c