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.
