Re: new scrub code vs zoned file systems

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

On 2023/5/31 22:17, Christoph Hellwig wrote:
> On Wed, May 31, 2023 at 02:04:05PM +0000, Johannes Thumshirn wrote:
>>
>> Heh and this has never actually worked IMHO.
>>
>> I did a crude hack to bandaid scrub:
>
> I think the better approach is to:
>
>   a) branch out at a very high level to the zoned code in
>      flush_scrub_stripes, or in fact even higher given that we
>      don't really care about tracking stripes.  The write
>      side of scrub has to work at a zone, not stripe level for
>      zoned devices

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 I'm more concerned about why we have a full zone before that crash.

>   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.

Thanks,
Qu