On 12/17/24 12:54 PM, Jens Axboe wrote: > io_uring does support ordering writes - not because of zoning, but to > avoid buffered writes being spread over a bunch of threads and hence > just hammering the inode mutex rather than doing actual useful work. You > could potentially use that. Then all pending writes for that inode would > be ordered, even if punted to io-wq. See io_uring/io_uring.c:io_prep_async_work(), which is called when an IO is added for io-wq execution, io_wq_hash_work() makes sure it'll be ordered. However, this will still not work if you're driving beyond the limit of the device queue depth, or if you're doing IOs that may trigger -EAGAIN spuriously for -EAGAIN as you can still have two issuers - the task itself submitting IO, and the one io-wq worker tasked with doing blocking writes on this zoned device. At the end of the day, expecting device side ordering and allowing > 1 in QD will always be inherently broken for zoned devices imho. Just don't do that... If you allow that and expect ordering, you're always going to be chasing cases where it breaks. -- Jens Axboe
