Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: j4shW0UZ08ARf5SMTahy3FEb8KJ7PGDhrwbKbpiWD3fmbmLbp/q2hRXUi5JZ3e5YcrLrgopDu0
 zMxp1dgCv19a6FFA0+55z8I3BUMDUPyi5vSuxlxOhYyWg5+L/fXJod4NASSXYUUN77j7jkmvsE
 qBIfxcabP2HrlQhtCGUxkpGJHpoli69y0AfxXgNBxXRUMhqcEPSidOQwccWydhv6cV03VNcpft
 rtolQyXlZO76CxuPTVehWyFz/CYx3HF2/4Ard2Y7ryOiQfD/OzzI5Ad6RoKytqW8+ZrvCcarLM
 e9M=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     "hch@infradead.org" <hch@infradead.org>
CC:     Kanchan Joshi <joshiiitr@gmail.com>, Jens Axboe <axboe@kernel.dk>,
        Pavel Begunkov <asml.silence@gmail.com>,
        Kanchan Joshi <joshi.k@samsung.com>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "bcrl@kvack.org" <bcrl@kvack.org>,
        Matthew Wilcox <willy@infradead.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-aio@kvack.org" <linux-aio@kvack.org>,
        "io-uring@vger.kernel.org" <io-uring@vger.kernel.org>,
        "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
        "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
        SelvaKumar S <selvakuma.s1@samsung.com>,
        Nitesh Shetty <nj.shetty@samsung.com>,
        Javier Gonzalez <javier.gonz@samsung.com>,
        Johannes Thumshirn <Johannes.Thumshirn@wdc.com>,
        Naohiro Aota <Naohiro.Aota@wdc.com>
Subject: Re: [PATCH v4 6/6] io_uring: add support for zone-append
Thread-Topic: [PATCH v4 6/6] io_uring: add support for zone-append
Thread-Index: AQHWYdbcc0q15qREKECGO7brHi6zEg==
Date:   Fri, 14 Aug 2020 12:20:34 +0000
Message-ID: <CY4PR04MB37518A2859396BCE0EEF5270E7400@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <CA+1E3rLM4G4SwzD6RWsK6Ssp7NmhiPedZDjrqN3kORQr9fxCtw@mail.gmail.com>
 <MWHPR04MB375863C20C1EF2CB27E62703E74E0@MWHPR04MB3758.namprd04.prod.outlook.com>
 <20200731091416.GA29634@infradead.org>
 <MWHPR04MB37586D39CA389296CE0252A4E74E0@MWHPR04MB3758.namprd04.prod.outlook.com>
 <20200731094135.GA4104@infradead.org>
 <MWHPR04MB3758A4B2967DB1FABAAD9265E74E0@MWHPR04MB3758.namprd04.prod.outlook.com>
 <20200731125110.GA11500@infradead.org>
 <CY4PR04MB37517D633920E4D31AC6EA0DE74B0@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200814081411.GA16943@infradead.org>
 <CY4PR04MB3751DE1ECCA4099902AABAA6E7400@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200814120422.GA1872@infradead.org>
Accept-Language: en-US
Content-Language: en-US
wdcipoutbound: EOP-TRUE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 60a007b8-7631-4937-0298-08d8404c71c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2020 12:20:34.2692
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b61c8803-16f3-4c35-9b17-6f65f441df86
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +5lB5ETxnlTMmNcsRFAuY5oTAXWcmN+BospLiwJ1W3wBYasFhBPEOsJWIClPd/jKhd5GlZycOj3x/7h46kkscg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB3749
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2020/08/14 21:04, hch@infradead.org wrote:=0A=
> On Fri, Aug 14, 2020 at 08:27:13AM +0000, Damien Le Moal wrote:=0A=
>>>=0A=
>>> O_APPEND pretty much implies out of order, as there is no way for an=0A=
>>> application to know which thread wins the race to write the next chunk.=
=0A=
>>=0A=
>> Yes and no. If the application threads do not synchronize their calls to=
=0A=
>> io_submit(), then yes indeed, things can get out of order. But if the=0A=
>> application threads are synchronized, then the offset set for each appen=
d AIO=0A=
>> will be in sequence of submission, so the user will not see its writes=
=0A=
>> completing at different write offsets than this implied offsets.=0A=
> =0A=
> Nothing gurantees any kind of ordering for two separate io_submit calls.=
=0A=
> The kernel may delay one of them for any reason.=0A=
=0A=
Ah. Yes. The inode locking is at the single aio issuing level, not the io_s=
ubmit=0A=
syscall level... So yes, in the end, the aios offsets and their execution o=
rder=0A=
can be anything. I see it now. So O_APPEND implying zone append is fine for=
 zonefs.=0A=
=0A=
> =0A=
> Now if you are doing two fully synchronous write calls on an=0A=
> O_APPEND fd, yes they are serialized.  But using Zone Append won't=0A=
> change that.=0A=
=0A=
Yep. That zonefs already does.=0A=
=0A=
OK. So I think I will send a writeup of the semantic discussed so far. We a=
lso=0A=
still need a solution for io_uring interface for the written offset report =
and=0A=
we can implement.=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=