Re: new scrub code vs zoned file systems

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2023/6/1 12:40, Christoph Hellwig wrote:
> On Thu, Jun 01, 2023 at 10:09:24AM +0800, Qu Wenruo wrote:
>> So far the various wrapper around the write operations work as expected,
>> and hide the detailed well enough that most of us didn't even notice.
>>
>> E.g. all the zoned code is already handled in scrub_write_sectors().
>>
>> The crash itself is caused by the fact that end io part is relying on
>> the inode pointer, that itself is a simple fix.
>
> But the reason why it is relying on the inode pointer is that it needs
> to record the actual written LBA after I/O completion.  So it's not
> just a case of just add a NULL check, it needs a way to adjust the
> logical to physical mapping from the dummy added before the I/O.

That's all handled by scrub.

For scrub we're doing the writes just like metadata, with QD=1, aka,
always write and wait (and know where the write would land), and for the
gaps we would call fill_writer_pointer_gap() to fill them.

Thus we don't need to do any adjustment (unless you're talking about
RST, but I believe that's a different beast).

>
>> But I'm more concerned about why we have a full zone before that crash.
>
> I think this is happening because we can't account for the zone filling
> without the proper context.

I believe it's a different problem, maybe some de-sync between scrub
write_pointer and the real zoned pointer inside the device.

My current guess is, the target zone inside the target device is not
properly reset before dev-replace.

Thanks,
Qu

>
>>>    b) don't create a new relocation thread per zone, but run it from
>>>       the scrub context.
>>>
>>
>> That's a little too complex, the problem is that relocation is a
>> completely different beast, too different from the scrub code.
>>
>> But I agree the repair part for zoned needs some rework, it's not
>> working from the day 1 of zoned support, but shouldn't need that a huge
>> change.
>>
>> E.g. we just record that we need to relocate the bg, then after the
>> scrub of that bg is fully finished, queue a relocation for it.
>
> Yes.  That's what the read repair already does, and also the scrub
> code, although in a somewhat sub-optimal way.
>
>>
>> Thanks,
>> Qu
> ---end quoted text---