lkml.org 
[lkml]   [2020]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v4 6/6] io_uring: add support for zone-append
Date
On 2020/08/14 21:04, hch@infradead.org 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

\
 
 \ /
  Last update: 2020-08-14 14:21    [W:0.139 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site