On 2020/07/21 5:17, Kanchan Joshi wrote:
> On Mon, Jul 20, 2020 at 10:44 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>>
>> On Mon, Jul 20, 2020 at 10:19:57PM +0530, Kanchan Joshi wrote:
>>> On Fri, Jul 10, 2020 at 7:41 PM Kanchan Joshi <joshiiitr@xxxxxxxxx> wrote:
>>>> If we are doing this for zone-append (and not general cases), "__s64
>>>> res64" should work -.
>>>> 64 bits = 1 (sign) + 23 (bytes-copied: cqe->res) + 40
>>>> (written-location: chunk_sector bytes limit)
>>
>> No, don't do this.
>>
>> struct io_uring_cqe {
>> __u64 user_data; /* sqe->data submission passed back */
>> - __s32 res; /* result code for this event */
>> - __u32 flags;
>> + union {
>> + struct {
>> + __s32 res; /* result code for this event */
>> + __u32 flags;
>> + };
>> + __s64 res64;
>> + };
>> };
>>
>> Return the value in bytes in res64, or a negative errno. Done.
>
> I concur. Can do away with bytes-copied. It's either in its entirety
> or not at all.
>
SAS SMR drives may return a partial completion. So the size written may be less
than requested, but not necessarily 0, which would be an error anyway since any
condition that would lead to 0B being written will cause the drive to fail the
command with an error.
Also, the completed size should be in res in the first cqe to follow io_uring
current interface, no ?. The second cqe would use the res64 field to return the
written offset. Wasn't that the plan ?
--
Damien Le Moal
Western Digital Research
