runner:fix the ret when reopen dev failed in cmd stpg

[lmh10144360]

if the device with the successful close()
but failed open() in tcmu_acquire_dev_lock,after
the cmd stpg failed,the device will never reopen
again。so change the ret from TCMU_STS_FENCED to
TCMU_STS_TIMEOUT,let the device into the recovery
list.

Signed-off-by: 李明辉10144360 [email protected]

[mikechristie]

I didn't understand the problem description. Did this patch:

commit 08e3a0e
Author: Mike Christie [email protected]
Date: Tue Sep 11 18:48:13 2018 -0500

runner: don't drop iscsi connection on lock fence errors

cause a bug for you?

We can't go into that if block that does tcmu_notify_conn_lost because it causes the path bouncing which can end up in the command retries being used up and paths not being added.

In your case is the following happening:

1. TCMU_STS_FENCED is returned to tcmu_explicit_transition and that gets translated to a SCSI BUSY status.
2. The initiator gets BUSY and retries.
3. tcmu-runner gets the STPG and calls tcmu_acquire_dev_lock again. It sees that TCMUR_DEV_FLAG_IS_OPEN is not set, so it calls tcmu_reopen_dev.

In your case is the initiator not retrying the BUSY status? Is it because the initiator does not retry for that SCSI status code or is it being retired so many times that the cmd has run out of retries? If either of those, what is the initiator OS?

[lmh10144360]

Thanks for reply !
yes,it is being retried，but when the cmd timeout is reached in scsi level，
it will finish the command with failed !
with the initiator OS centos7.4，the timeout is setted to 360S，if stpg is not
return ok in 360S，the cmd will be failed, and will not be retried anymore.

[mikechristie]

Hey, Sorry for the late reply.

It looks like you have the same problem with TCMU_STS_TIMEOUT. Won't you have limited retries for that case too?

What is your pg_init_retries set to on the initiator side in /etc/multipath.conf?