Re: [PATCH 2/2] block: Split and submit bios in LBA order

[Bart Van Assche <bvanassche@acm.org>]

On 3/25/23 18:45, Damien Le Moal wrote:
> On 3/26/23 01:31, Bart Van Assche wrote:
>> Although the above sounds interesting to me, I think the following two
>> scenarios are not handled by the above approach and can lead to reordering:
>> * The SCSI device reporting a unit attention.
>> * The SCSI device responding with the SCSI status "BUSY". The UFS
>> standard explicitly allows this. From the UFS standard: "If the unit is
>> not ready to accept a new command (e.g., still processing previous
>> command) a STATUS response of BUSY will be returned."
> 
> Yes, that likely would be an issue for regular writes, but likely not for zone
> append emulation using regular writes though, since a "busy" return for a ZA
> emulated regular write can be resent later with a different aligned write location.

Hi Damien,

If a SCSI device responds with status "BUSY" or a unit attention for a 
zone append operation, all pending REQ_OP_ZONE_APPEND operations that 
have already been translated into WRITE commands will fail because of a 
write pointer mismatch. I'm wondering whether the following would be 
sufficient to support multiple pending REQ_OP_ZONE_APPEND operations 
when translating these into SCSI WRITE commands:
* If a zoned write operation is not executed (SAM_STAT_BUSY,
   SAM_STAT_CHECK_CONDITION, ...), change the host state to
   SHOST_RECOVERY to prevent that pending zone append operations fail
   because of a write pointer mismatch.
* After all pending SCSI commands have failed, completed or timed out,
   resubmit these commands. For REQ_OP_ZONE_APPEND, this may result in a
   new LBA being selected when translating these into WRITE commands.
* Retry commands that fail with UNALIGNED WRITE COMMAND until the retry
   count is exhausted.
* Increase the retry count for REQ_OP_ZONE_APPEND operations such that
   the above retry mechanism neither causes an infinite loop nor failures
   because the device responds with SAM_STAT_BUSY or a unit attention.

Thanks,

Bart.