On 2020-03-02 21:18, David Sterba wrote:
On Sun, Mar 01, 2020 at 06:58:02PM +0100, Holger Hoffstätte wrote:
On 1/17/20 3:08 PM, Josef Bacik wrote:
+ alloc_flags = btrfs_get_alloc_profile(fs_info, cache->flags);
if (alloc_flags != cache->flags) {
ret = btrfs_chunk_alloc(trans, alloc_flags,
CHUNK_ALLOC_FORCE);
@@ -2252,7 +2204,7 @@ int btrfs_inc_block_group_ro(struct btrfs_block_group *cache,
ret = inc_block_group_ro(cache, 0);
out:
if (cache->flags & BTRFS_BLOCK_GROUP_SYSTEM) {
- alloc_flags = update_block_group_flags(fs_info, cache->flags);
+ alloc_flags = btrfs_get_alloc_profile(fs_info, cache->flags);
mutex_lock(&fs_info->chunk_mutex);
check_system_chunk(trans, alloc_flags);
mutex_unlock(&fs_info->chunk_mutex);
It seems that this patch breaks forced metadata rebalance from dup to single;
all chunks remain dup (or are rewritten as dup again). I bisected the broken
balance behaviour to this commit which for some reason was in my tree ;-) and
reverting it immediately fixed things.
I don't (yet) see this applied anywhere, but couldn't find any discussion or
revocation either. Maybe the logic between update_block_group_flags() and
btrfs_get_alloc_profile() is not completely exchangeable?
The patch was not applied because I was not sure about it and had some
suspicion, https://lore.kernel.org/linux-btrfs/20200108170340.GK3929@xxxxxxxxxxxxx/
I don't want to apply the patch until I try the mentioned test with
raid1c34 but it's possible that it gets fixed by the updated patch.
I don't see this in misc-next or anywhere else, so a gentle reminder..
Original thread:
https://lore.kernel.org/linux-btrfs/20200117140826.42616-1-josef@xxxxxxxxxxxxxx/
As I wrote in the replies, the update to the patch fixed the balancing for me
(used with various profiles since then, no observed issues).
Josef, what about that xfstest?
David, can you try again with raid1c34?
thanks
Holger
