Re: [PATCH 0/3] implement direct IO with integrity

[Jens Axboe <axboe@kernel.dk>]

On 10/28/21 11:11 AM, Pavel Begunkov wrote:
> On 10/28/21 17:22, Jens Axboe wrote:
>> On 10/28/21 9:56 AM, Pavel Begunkov wrote:
>>> On 10/28/21 16:50, Jens Axboe wrote:
>>>> On 10/28/21 9:44 AM, Mikhail Malygin wrote:
>>>>> Thanks for the feedback, we’ll submit and updated version of the series.
>>>>>
>>>>> The only question is regarding uapi: should we add a separate opcodes
>>>>> for read/write or use existing opcodes with the flag in the
>>>>> io_uring_sqe.rw_flags field?
>>>>>
>>>>> The flag was discussed in the another submission, where it was
>>>>> considered to be a better approach over opcodes:
>>>>> https://patchwork.kernel.org/project/linux-block/patch/20200226083719.4389-2-bob.liu@oracle.com/
>>>>
>>>> Separate opcodes is, at least to me, definitely the way to go. Just
>>>> looking at the code needing to tap into weird spots for PI is enough to
>>>> make that call. On top of that, it also allows you to cleanly define
>>>> this command and (hopefully?) avoid that weirdness with implied PI in
>>>> the last iovec.
>>>
>>> Reminds me struggles with writing encoded data to btrfs. I believe
>>> Omar did go for RWF_ENCODED flag, right?
>>
>> Exactly the same problem, yes. It ends up being pretty miserable, and
>> there's no reason to go through that misery when we're not bound by only
>> passing in an iovec.
> 
> I agree that a new opcode is better, at least we can keep the overhead
> out of the common path, but RWF_ENCODED was having similar problems
> (e.g. passing metadata in iov), so that's interesting why RWF was chosen
> in the end. Is it only to support readv/writev(2) or something else?

To shoe horn it in via an existing interface, I don't think anybody
wanted to add yet another read/write API just to cater to that.

-- 
Jens Axboe