On Tue, Jun 30, 2020 at 02:17:18PM -0400, Josef Bacik wrote:
> btrfs/061 has been failing consistently for me recently with a
> transaction abort. We run out of space in the system chunk array, which
> means we've allocated way too many system chunks than we need.
>
> Chris added this a long time ago for balance as a poor mans restriping.
> If you had a single disk and then added another disk and then did a
> balance, update_block_group_flags would then figure out which RAID level
> you needed.
>
> Fast forward to today and we have restriping behavior, so we can
> explicitly tell the fs that we're trying to change the raid level. This
> is accomplished through the normal get_alloc_profile path.
>
> Furthermore this code actually causes btrfs/061 to fail, because we do
> things like mkfs -m dup -d single with multiple devices. This trips
> this check
>
> alloc_flags = update_block_group_flags(fs_info, cache->flags);
> if (alloc_flags != cache->flags) {
> ret = btrfs_chunk_alloc(trans, alloc_flags, CHUNK_ALLOC_FORCE);
>
> in btrfs_inc_block_group_ro. Because we're balancing and scrubbing, but
> not actually restriping, we keep forcing chunk allocation of RAID1
> chunks. This eventually causes us to run out of system space and the
> file system aborts and flips read only.
>
> We don't need this poor mans restriping any more, simply use the normal
> get_alloc_profile helper, which will get the correct alloc_flags and
> thus make the right decision for chunk allocation. This keeps us from
> allocating a billion system chunks and falling over.
>
> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
1 and 2 added to misc-next. I haven't found time to verify the raid1c34
case, but Holger reported it had fixed some problems for him I take
that as testing.
