On 1/9/23 15:51, Damien Le Moal wrote:
On 1/10/23 08:27, Bart Van Assche wrote:
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 47dafe6b8a66..cd90b54a6597 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1207,6 +1207,9 @@ static blk_status_t sd_setup_read_write_cmnd(struct scsi_cmnd *cmd)
cmd->transfersize = sdp->sector_size;
cmd->underflow = nr_blocks << 9;
cmd->allowed = sdkp->max_retries;
+ if (blk_queue_pipeline_zoned_writes(rq->q) &&
+ blk_rq_is_seq_zone_write(rq))
+ cmd->allowed += rq->q->nr_requests;
cmd->sdb.length = nr_blocks * sdp->sector_size;
SCSI_LOG_HLQUEUE(1,
Aouch... The amount of IO errors logged in the the kernel log will not be
pretty, no ?
At least for scsi disks, the problem is that a write may partially fail
(the command hit a bad sector). Such write failure will cause all queued
writes after it to fail and no amount of retry will help. Not sure about
UFS devices though. Can you get a partial failure ?
Although the UFS specification supports residuals, one of the open bugs
in the UFS driver is that the residual field from the UFS device
response is ignored. I think this means that no UFS device vendor cares
enough about partial failures to implement support for partial failures.
Please let me know if you want me to look into suppressing error
messages triggered by this new retry mechanism.
Thanks,
Bart.
