Re: new scrub code vs zoned file systems

[Christoph Hellwig <hch@lst.de>]

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.

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

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