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.