The handling of the ALUA transitioning state is currently broken. When
a target goes into this state, it is expected that the target is
allowed to stay in this state for the implicit transition timeout
without a path failure. The handler has this logic, but it gets
skipped currently.
When the target transitions, there is in-flight I/O from the
initiator. The first of these responses from the target will be a unit
attention letting the initiator know that the ALUA state has changed.
The remaining in-flight I/Os, before the initiator finds out that the
portal state has changed, will return not ready, ALUA state is
transitioning. The portal state will change to
SCSI_ACCESS_STATE_TRANSITIONING. This will lead to all new I/O
immediately failing the path unexpectedly. The path failure happens in
less than a second instead of the expected successes until the
transition timer is exceeded.
This change allows I/Os to continue while the path is in the ALUA
transitioning state. The handler already takes care of a target that
stays in the transitioning state for too long by changing the state to
ALUA state standby once the transition timeout is exceeded at which
point the path will fail.
Signed-off-by: Brian Bunker <brian@xxxxxxxxxxxxxxx>
Acked-by: Krishna Kant <krishna.kant@xxxxxxxxxxxxxxx>
Acked-by: Seamus Connor <sconnor@xxxxxxxxxxxxxxx>
___
diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
b/drivers/scsi/device_handler/scsi_dh_alua.c
index 37d06f993b76..1d9be771f3ee 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -1172,9 +1172,8 @@ static blk_status_t alua_prep_fn(struct
scsi_device *sdev, struct request *req)
case SCSI_ACCESS_STATE_OPTIMAL:
case SCSI_ACCESS_STATE_ACTIVE:
case SCSI_ACCESS_STATE_LBA:
- return BLK_STS_OK;
case SCSI_ACCESS_STATE_TRANSITIONING:
- return BLK_STS_AGAIN;
+ return BLK_STS_OK;
default:
req->rq_flags |= RQF_QUIET;
return BLK_STS_IOERR;
--
Brian Bunker
PURE Storage, Inc.
brian@xxxxxxxxxxxxxxx
