On 2020/08/14 21:04, hch@xxxxxxxxxxxxx wrote: > On Fri, Aug 14, 2020 at 08:27:13AM +0000, Damien Le Moal wrote: >>> >>> 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
