Re: [PATCH v4] btrfs: zoned: reserve data_reloc block group on mount

[Johannes Thumshirn <Johannes.Thumshirn@wdc.com>]

On 03.06.25 16:07, Filipe Manana wrote:
> On Tue, Jun 3, 2025 at 12:23 PM Johannes Thumshirn
> <Johannes.Thumshirn@wdc.com> wrote:
>>
>> On 03.06.25 08:14, Johannes Thumshirn wrote:
>>> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>>>
>>> Create a block group dedicated for data relocation on mount of a zoned
>>> filesystem.
>>>
>>> If there is already more than one empty DATA block group on mount, this
>>> one is picked for the data relocation block group, instead of a newly
>>> created one.
>>>
>>> This is done to ensure, there is always space for performing garbage
>>> collection and the filesystem is not hitting ENOSPC under heavy overwrite
>>> workloads.
>>>
>>> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>>> Reviewed-by: Filipe Manana <fdmanana@suse.com>
>>
>> Unfortunately this can result in a FS corruption if the accompanying
>> mkfs patch is not applied.
>>
>> I think it is, because I'm not waiting for the transaction to be written
>> out in case we need to allocate a chunk. Therefor metadata on DUP can
>> get out of sync somehow when one copy is on a sequential zone and one on
>> a conventional zone.
> 
> Not familiar with the zone specific problems, but in order to use a
> new chunk, there's no need to commit a transaction.
> And if for some weird reason that is a problem for the zoned case, how
> about committing the transaction after allocating the chunk? Does it
> still cause any issue?

AFAICT yes. And it's a very wired case that only happens on DUP metadata 
and the metadata bg has to be backed by a conventional and a sequential 
zone.

The problem is, every hypothesis I have how this could happen is 
invalidated by looking at the code. Basically what must happen is that 
more than one chunk is created backed by the same zone, which according 
to the code can't happen.