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.
