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: fUThbbkSQNjXUFL+1mFzroCsQqv9aLCpWp+uu2M+x0DsMtq00ngcSlok3TDgDDj5BTDXO7ul5L
 INSfBypDg44qrwoWsJpv16//vQuhpPTirhKPlw1jbb1ucgrSDpIJdCEdnTX1xUXw+kHlF1XPSo
 kYJhAMb50aJM1KvD9SgJ8hA+7YGd92Xoke5CLDZUFKfywOm4OgJNmKgSF3vSwcKCrMpwp77IqV
 0jwDprdi5pYJ5gqYjnUEVCVyKeyS5+CY3U3ksF/OXPwhVb9B94DbUqXlEUdVhVOmjy75UTfz0Y
 S5w=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Kanchan Joshi <joshi.k@samsung.com>,
        "hch@infradead.org" <hch@infradead.org>
CC:     "axboe@kernel.dk" <axboe@kernel.dk>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "bcrl@kvack.org" <bcrl@kvack.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>,
        "selvakuma.s1@samsung.com" <selvakuma.s1@samsung.com>,
        "nj.shetty@samsung.com" <nj.shetty@samsung.com>,
        "javier.gonz@samsung.com" <javier.gonz@samsung.com>
Subject: Re: [PATCH 0/3] zone-append support in aio and io-uring
Thread-Topic: [PATCH 0/3] zone-append support in aio and io-uring
Thread-Index: AQHWRMyErNBfEVsLrU+xBQX5pX+rOw==
Date:   Fri, 19 Jun 2020 03:08:33 +0000
Message-ID: <CY4PR04MB37515E4FCD1EAA5880E2E1A2E7980@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <CGME20200617172653epcas5p488de50090415eb802e62acc0e23d8812@epcas5p4.samsung.com>
 <1592414619-5646-1-git-send-email-joshi.k@samsung.com>
 <20200618065634.GB24943@infradead.org> <20200618175258.GA4141152@test-zns>
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: 7ba96318-441b-4b32-b60a-08d813fe0d33
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2020 03:08:33.5909
 (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: MY0lI43d7+EtG7UXHNOU9tUs9YdWL/HLUBwrX124jxNbFS3io0MJvXnVtVKIkFzgIBgAJMDYWAc5qfWXMUhxvw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB1049
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/06/19 2:55, Kanchan Joshi wrote:=0A=
> On Wed, Jun 17, 2020 at 11:56:34PM -0700, Christoph Hellwig wrote:=0A=
>> On Wed, Jun 17, 2020 at 10:53:36PM +0530, Kanchan Joshi wrote:=0A=
>>> This patchset enables issuing zone-append using aio and io-uring direct=
-io interface.=0A=
>>>=0A=
>>> For aio, this introduces opcode IOCB_CMD_ZONE_APPEND. Application uses =
start LBA=0A=
>>> of the zone to issue append. On completion 'res2' field is used to retu=
rn=0A=
>>> zone-relative offset.=0A=
>>>=0A=
>>> For io-uring, this introduces three opcodes: IORING_OP_ZONE_APPEND/APPE=
NDV/APPENDV_FIXED.=0A=
>>> Since io_uring does not have aio-like res2, cqe->flags are repurposed t=
o return zone-relative offset=0A=
>>=0A=
>> And what exactly are the semantics supposed to be?  Remember the=0A=
>> unix file abstractions does not know about zones at all.=0A=
>>=0A=
>> I really don't think squeezing low-level not quite block storage=0A=
>> protocol details into the Linux read/write path is a good idea.=0A=
> =0A=
> I was thinking of raw block-access to zone device rather than pristine fi=
le=0A=
> abstraction. And in that context, semantics, at this point, are unchanged=
=0A=
> (i.e. same as direct writes) while flexibility of async-interface gets=0A=
> added.=0A=
=0A=
The aio->aio_offset use by the user and kernel differs for regular writes a=
nd=0A=
zone append writes. This is a significant enough change to say that semanti=
c=0A=
changed. Yes both cases are direct IOs, but specification of the write loca=
tion=0A=
by the user and where the data actually lands on disk are different.=0A=
=0A=
There are a lot of subtle things that can happen that makes mapping of zone=
=0A=
append operations to POSIX semantic difficult. E.g. for a regular file, usi=
ng=0A=
zone append for any write issued to a file open with O_APPEND maps well to =
POSIX=0A=
only for blocking writes. For asynchronous writes, that is not true anymore=
=0A=
since the order of data defined by the automatic append after the previous =
async=0A=
write breaks: data can land anywhere in the zone regardless of the offset=
=0A=
specified on submission.=0A=
=0A=
> Synchronous-writes on single-zone sound fine, but synchronous-appends on=
=0A=
> single-zone do not sound that fine.=0A=
=0A=
Why not ? This is a perfectly valid use case that actually does not have an=
y=0A=
semantic problem. It indeed may not be the  most effective method to get hi=
gh=0A=
performance but saying that it is "not fine" is not correct in my opinion.=
=0A=
=0A=
> =0A=
>> What could be a useful addition is a way for O_APPEND/RWF_APPEND writes=
=0A=
>> to report where they actually wrote, as that comes close to Zone Append=
=0A=
>> while still making sense at our usual abstraction level for file I/O.=0A=
> =0A=
> Thanks for suggesting this. O and RWF_APPEND may not go well with block=
=0A=
> access as end-of-file will be picked from dev inode. But perhaps a new=0A=
> flag like RWF_ZONE_APPEND can help to transform writes (aio or uring)=0A=
> into append without introducing new opcodes.=0A=
=0A=
Yes, RWF_ZONE_APPEND may be better if the semantic of RWF_APPEND cannot be=
=0A=
cleanly reused. But as Christoph said, RWF_ZONE_APPEND semantic need to be=
=0A=
clarified so that all reviewer can check the code against the intended beha=
vior,=0A=
and comment on that intended behavior too.=0A=
=0A=
> And, I think, this can fit fine on file-abstraction of ZoneFS as well.=0A=
=0A=
May be. Depends on what semantic you are after for user zone append interfa=
ce.=0A=
Ideally, we should have at least the same for raw block device and zonefs. =
But=0A=
zonefs may be able to do a better job thanks to its real regular file=0A=
abstraction of zones. As Christoph said, we started looking into it but lac=
ked=0A=
time to complete this work. This is still on-going.=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=