Re: [PATCH v2 0/2] zone-append support in io-uring and aio

[Kanchan Joshi <joshi.k@samsung.com>]

[-- Attachment #1: Type: text/plain, Size: 3497 bytes --]

On Fri, Jun 26, 2020 at 03:11:55AM +0000, Damien Le Moal wrote:
>On 2020/06/26 2:18, Kanchan Joshi wrote:
>> Semantics --->
>> Zone-append, by its nature, may perform write on a different location than what
>> was specified. It does not fit into POSIX, and trying to fit may just undermine
>> its benefit. It may be better to keep semantics as close to zone-append as
>> possible i.e. specify zone-start location, and obtain the actual-write location
>> post completion. Towards that goal, existing async APIs seem to fit fine.
>> Async APIs (uring, linux aio) do not work on implicit write-pointer and demand
>> explicit write offset (which is what we need for append). Neither write-pointer
>
>What do you mean by "implicit write pointer" ? Are you referring to the behavior
>of AIO write with a block device file open with O_APPEND ? The yes, it does not
>work. But that is perfectly fine for regular files, that is for zonefs.
Sorry, I meant file pointer.
Yes, block-device opened with O_APPEND does not increase the file-pointer
to end-of-device. That said, for uring and aio, file-pointer position
plays no role, and it is application responsibility to pass the right write
location.
>I would prefer that this paragraph simply state the semantic that is implemented
>first. Then explain why the choice. But first, clarify how the API works, what
>is allowed, what's not etc. That will also simplify reviewing the code as one
>can then check the code against the goal.

In this path (block IO) there is hardly any scope/attempt to abstract away anything.
So raw zoned-storage rule/semantics apply. I expect zone-aware
applications, which are already aware of rules, to be consumer of this.

>> is taken as input, nor it is updated on completion. And there is a clear way to
>> get zone-append result. Zone-aware applications while using these async APIs
>> can be fine with, for the lack of better word, zone-append semantics itself.
>>
>> Sync APIs work with implicit write-pointer (at least few of those), and there is
>> no way to obtain zone-append result, making it hard for user-space zone-append.
>
>Sync API are executed under inode lock, at least for regular files. So there is
>absolutely no problem to use zone append. zonefs does it already. The problem is
>the lack of locking for block device file.
Yes. I was refering to the problem of returning actual write-location using
sync APIs like write, pwrite, pwritev/v2.
>>
>> Tests --->
>> Using new interface in fio (uring and libaio engine) by extending zbd tests
>> for zone-append: https://protect2.fireeye.com/url?k=e21dd5e0-bf837b7a-e21c5eaf-0cc47a336fae-c982437ed1be6cc8&q=1&u=https%3A%2F%2Fgithub.com%2Faxboe%2Ffio%2Fpull%2F1026
>>
>> Changes since v1:
>> - No new opcodes in uring or aio. Use RWF_ZONE_APPEND flag instead.
>> - linux-aio changes vanish because of no new opcode
>> - Fixed the overflow and other issues mentioned by Damien
>> - Simplified uring support code, fixed the issues mentioned by Pavel
>> - Added error checks
>>
>> Kanchan Joshi (1):
>>   fs,block: Introduce RWF_ZONE_APPEND and handling in direct IO path
>>
>> Selvakumar S (1):
>>   io_uring: add support for zone-append
>>
>>  fs/block_dev.c          | 28 ++++++++++++++++++++++++----
>>  fs/io_uring.c           | 32 ++++++++++++++++++++++++++++++--
>>  include/linux/fs.h      |  9 +++++++++
>>  include/uapi/linux/fs.h |  5 ++++-
>>  4 files changed, 67 insertions(+), 7 deletions(-)
>>
>
>
>-- 
>Damien Le Moal
>Western Digital Research
>

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]