Re: [PATCH v2 3/4] block: Prevent potential deadlocks in zone write plug error recovery

[Christoph Hellwig <hch@lst.de>]

On Mon, Dec 09, 2024 at 07:57:57AM +0900, Damien Le Moal wrote:
> Avoid this problem by completely getting rid of the need for executing a
> report zone from within the zone write plugging code, instead relying on
> the user either executing a report zones, resetting the zone or
> finishing the zone of a failed write. This is not an unresannable

s/unresannable/unreasonable/ ?

> requirement as all well-behaved applications, FSes and device mapper
> already use report zones to recover from write errors whenever possible.

I think the real question here is what errors the file system (or other
submitter) can even recover from.  The next patch deals with the not
support case for a "special" operation, and that's of course a valid one.
The first patch already excludes EAGAIN from nowait, and the drivers
already retry anything that they think is retryable by just resubmitting
without bubbling it up to the submitter.  That mostly leaves fatal
media errors as all modern hardware that supports zones just remaps
on write media failures.  I.e. for those the most sane answer is to
simply shut down the file system for single-device file systems, or
treat the device as faulty for multi-device file systems.  This might
change when we support logical depop on a per-zone basis, but I don't
think anyone is there yet.  We also really should test this case.
I'll add a testcase with error injection for zoned xfs, and someone
should do the same for btrfs (including multi-device handling) and
f2fs.

Sorry for the long rant - not a comment on the code itself but maybe
the commit log could use a little update.

Also we probably need to recover this information somewhere in the
docs.