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: IMasm45IrxfmgBkR1INEaDQbODV27Nm5xjh2IO804RshWmjNk0kRLzbVIpIUXG39d3nR0GAEIe
 oQxFWkdCbTw1ihjZbMMC5Y5TNDC/27Y4ffQ8pX4rn1hq7z35CpXj0i6HZjkdy+1t08vZtELRBL
 2oh7wTSz00Lja27a/itiIjwN54LbTdwUYLEyp+aepedcbcSzBLNN6L1GP1QRjmK9aJQJjiwzGW
 GUWMa0zT4wU5aTaokz3HlXOxDtpEkuLcW5KdRF8kJo3Vjh/nxi3ey092OBsx33iPnaFeTz3MkF
 r/8=
From:   Damien Le Moal <Damien.LeMoal@wdc.com>
To:     Matthew Wilcox <willy@infradead.org>
CC:     Kanchan Joshi <joshiiitr@gmail.com>,
        "hch@infradead.org" <hch@infradead.org>,
        Jens Axboe <axboe@kernel.dk>,
        Kanchan Joshi <joshi.k@samsung.com>,
        "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
        "bcrl@kvack.org" <bcrl@kvack.org>,
        "asml.silence@gmail.com" <asml.silence@gmail.com>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        Matias Bj??rling <mb@lightnvm.io>,
        "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>,
        Selvakumar S <selvakuma.s1@samsung.com>,
        Nitesh Shetty <nj.shetty@samsung.com>,
        Javier Gonzalez <javier.gonz@samsung.com>
Subject: Re: [PATCH v3 4/4] io_uring: add support for zone-append
Thread-Topic: [PATCH v3 4/4] io_uring: add support for zone-append
Thread-Index: AQHWUv1xEGaGdzUuiUilHzifWt+jQw==
Date:   Tue, 21 Jul 2020 02:19:04 +0000
Message-ID: <CY4PR04MB3751A6F034A6458AFA7A6550E7780@CY4PR04MB3751.namprd04.prod.outlook.com>
References: <CA+1E3rLna6VVuwMSHVVEFmrgsTyJN=U4CcZtxSGWYr_UYV7AmQ@mail.gmail.com>
 <20200710131054.GB7491@infradead.org>
 <20200710134824.GK12769@casper.infradead.org>
 <20200710134932.GA16257@infradead.org>
 <20200710135119.GL12769@casper.infradead.org>
 <CA+1E3rKOZUz7oZ_DGW6xZPQaDu+T5iEKXctd+gsJw05VwpGQSQ@mail.gmail.com>
 <CA+1E3r+j=amkEg-_KUKSiu6gt2TRU6AU-_jwnB1C6wHHKnptfQ@mail.gmail.com>
 <20200720171416.GY12769@casper.infradead.org>
 <CA+1E3rLNo5sFH3RPFAM4_SYXSmyWTCdbC3k3-6jeaj3FRPYLkQ@mail.gmail.com>
 <CY4PR04MB37513C3424E81955EE7BFDA4E7780@CY4PR04MB3751.namprd04.prod.outlook.com>
 <20200721011509.GB15516@casper.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: e68f927a-cd10-4ccd-7204-08d82d1c7071
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 02:19:04.0582
 (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: Ydrf1pWtGJ+Km92pDj2i4cmqcaSmwHjZ3BCG22reCv33zOioRVaJ538n/j9O87eS3ti8aFIJn+TeK314uXIKpg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR04MB1113
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/07/21 10:15, Matthew Wilcox wrote:=0A=
> On Tue, Jul 21, 2020 at 12:59:59AM +0000, Damien Le Moal wrote:=0A=
>> On 2020/07/21 5:17, Kanchan Joshi wrote:=0A=
>>> On Mon, Jul 20, 2020 at 10:44 PM Matthew Wilcox <willy@infradead.org> w=
rote:=0A=
>>>>  struct io_uring_cqe {=0A=
>>>>         __u64   user_data;      /* sqe->data submission passed back */=
=0A=
>>>> -       __s32   res;            /* result code for this event */=0A=
>>>> -       __u32   flags;=0A=
>>>> +       union {=0A=
>>>> +               struct {=0A=
>>>> +                       __s32   res;    /* result code for this event =
*/=0A=
>>>> +                       __u32   flags;=0A=
>>>> +               };=0A=
>>>> +               __s64           res64;=0A=
>>>> +       };=0A=
>>>>  };=0A=
>>>>=0A=
>>>> Return the value in bytes in res64, or a negative errno.  Done.=0A=
>>>=0A=
>>> I concur. Can do away with bytes-copied. It's either in its entirety=0A=
>>> or not at all.=0A=
>>>=0A=
>>=0A=
>> SAS SMR drives may return a partial completion. So the size written may =
be less=0A=
>> than requested, but not necessarily 0, which would be an error anyway si=
nce any=0A=
>> condition that would lead to 0B being written will cause the drive to fa=
il the=0A=
>> command with an error.=0A=
> =0A=
> Why might it return a short write?  And, given how assiduous programmers=
=0A=
> are about checking for exceptional conditions, is it useful to tell=0A=
> userspace "only the first 512 bytes of your 2kB write made it to storage"=
?=0A=
> Or would we rather just tell userspace "you got an error" and _not_=0A=
> tell them that the first N bytes made it to storage?=0A=
=0A=
If the write hits a bad sector on disk half-way through, a SAS drive may re=
turn=0A=
a short write with a non 0 residual. SATA drives will fail the entire comma=
nd=0A=
and libata will retry the failed command. That said, if the drive fails to =
remap=0A=
a bad sector and return an error to the host, it is generally an indicator =
that=0A=
one should go to the store to get a new drive :)=0A=
=0A=
Yes, you have a good point. Returning an error for the entire write would b=
e=0A=
fine. The typical error handling for a failed write to a zone is for the us=
er to=0A=
first do a zone report to inspect the zone condition and WP position, resyn=
c its=0A=
view of the zone state and restart the write in the same zone or somewhere =
else.=0A=
So failing the entire write is OK.=0A=
I am actually not 100% sure what the bio interface does if the "restart=0A=
remaining" of a partially failed request fails again after all retry attemp=
ts.=0A=
The entire BIO is I think failed. Need to check. So the high level user wou=
ld=0A=
not see the partial failure as that stays within the scsi layer.=0A=
=0A=
>> Also, the completed size should be in res in the first cqe to follow io_=
uring=0A=
>> current interface, no ?. The second cqe would use the res64 field to ret=
urn the=0A=
>> written offset. Wasn't that the plan ?=0A=
> =0A=
> two cqes for one sqe seems like a bad idea to me.=0A=
=0A=
Yes, this is not very nice. I got lost in the thread. I thought that was th=
e plan.=0A=
=0A=
=0A=
-- =0A=
Damien Le Moal=0A=
Western Digital Research=0A=