On 2020/08/14 21:04, hch@infradead.org wrote:

On Fri, Aug 14, 2020 at 08:27:13AM +0000, Damien Le Moal wrote:

quoted

quoted

O_APPEND pretty much implies out of order, as there is no way for an
application to know which thread wins the race to write the next chunk.

Yes and no. If the application threads do not synchronize their calls to
io_submit(), then yes indeed, things can get out of order. But if the
application threads are synchronized, then the offset set for each append AIO
will be in sequence of submission, so the user will not see its writes
completing at different write offsets than this implied offsets.

Nothing gurantees any kind of ordering for two separate io_submit calls.
The kernel may delay one of them for any reason.

Ah. Yes. The inode locking is at the single aio issuing level, not the io_submit
syscall level... So yes, in the end, the aios offsets and their execution order
can be anything. I see it now. So O_APPEND implying zone append is fine for zonefs.

Now if you are doing two fully synchronous write calls on an
O_APPEND fd, yes they are serialized.  But using Zone Append won't
change that.

Yep. That zonefs already does.

OK. So I think I will send a writeup of the semantic discussed so far. We also
still need a solution for io_uring interface for the written offset report and
we can implement.


-- 
Damien Le Moal
Western Digital Research