scsi_dh_alua: Re-enable STPG for unavailable ports
PATCH 1/1 scsi_dh_alua: Re-enable STPG for unavailable ports
A quote from SPC-4: "While in the unavailable primary target port asymmetric access state, the device server shall support those of the following commands that it supports while in the active/optimized
state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence re-enable sending STPG to a target port group that is in the unavailable state.
---
This patch fixes a regression introduced in kernel 3.5-rc1.
--- drivers/scsi/device_handler/scsi_dh_alua.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
drivers/scsi/device_handler/scsi_dh_alua.c +1 -1
@@ -691,9 +691,9 @@ static int alua_activate(struct scsi_device *sdev, stpg =0 ;break ;case TPGS_STATE_STANDBY : +case TPGS_STATE_UNAVAILABLE : stpg =1 ;break ; -case TPGS_STATE_UNAVAILABLE :case TPGS_STATE_OFFLINE : err =SCSI_DH_IO ;break ;
Bart,
Quoted 11 lines
-----Original Message-----
From: Bart Van Assche [mailto:[email protected]]
Sent: Friday, June 22, 2012 3:50 AM
To: linux-scsi; Moger, Babu; Hannes Reinecke
Subject: [PATCH]scsi_dh_alua: Re-enable STPG for unavailable portsA quote from SPC-4: "While in the unavailable primary target port asymmetric access state, the device server shall support those of the following commands that it supports while in the active/optimized
state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence re-enable sending STPG to a target port group that is in the unavailable state.
Patch looks good. One concern, the spec also says..
==============================
The unavailable target port asymmetric access state is
intended for situations when the target port accessibility to a logical unit may be severely restricted due to SCSI target device limitations (e.g., hardware errors). Therefore it may not be possible to transition from this state to either the active/optimized, active/non-optimized or standby states.
=====================================================
What happens if we cannot transition to active/optimized, active/non-optimized or standby states. Are we going to loop forever? From kernel side it looks ok. We are going mark the path as failed. It depends on what the path checker from multipath is going to do. Do you have any idea about it?
Quoted 28 lines
Signed-off-by Bart Van Assche <[email protected]>Cc Babu Moger <[email protected]>Cc Hannes Reinecke <[email protected]>---
This patch fixes a regression introduced in kernel 3.5-rc1.--- drivers/scsi/device_handler/scsi_dh_alua.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)drivers/scsi/device_handler/scsi_dh_alua.c +1
-1@@ -691,9 +691,9 @@ static int alua_activate(struct scsi_device *sdev, stpg =0 ;break ;case TPGS_STATE_STANDBY : +case TPGS_STATE_UNAVAILABLE : stpg =1 ;break ; -case TPGS_STATE_UNAVAILABLE :case TPGS_STATE_OFFLINE : err =SCSI_DH_IO ;break ;
Quoted 11 lines · Babu
One concern, the spec also says..
==============================
The unavailable target port asymmetric access state is
intended for situations when the target port accessibility to a logical unit may be severely restricted due to SCSI target device limitations (e.g., hardware errors). Therefore it may not be possible to transition from this state to either the active/optimized, active/non-optimized or standby states.
=====================================================What happens if we cannot transition to active/optimized, active/non-optimized or standby states. Are we going to loop forever? From kernel side it looks ok. We are going mark the path as failed. It depends on what the path checker from multipath is going to do. Do you have any idea about it?
Good question. I'm not a multipath expert, but as far as I understand the multipath user space software if activating a path fails after some delay multipathd tries again to find a usable I/O path.
Bart.
Moger, Babu
Reviewed-byQuoted 22 lines
-----Original Message-----
From: Bart Van Assche [mailto:[email protected]]
Sent: Friday, June 22, 2012 1:50 PM
To: Moger, Babu
Cc: linux-scsi; Hannes Reinecke
Subject: Re: [PATCH]scsi_dh_alua: Re-enable STPG for unavailable portsQuoted 4 lines · Babu
One concern, the spec also says..
==============================
The unavailable target port asymmetric access state is
intended for situations when the target port accessibility to a logical unitmay be severely restricted due to SCSI
Quoted 1 line
target device limitations (e.g., hardware errors). Therefore it may not be
possible to transition from this state to
Quoted 4 lines
either the active/optimized, active/non-optimized or standby states.
=====================================================What happens if we cannot transition to active/optimized, active/non-
optimized or standby states.
Quoted 1 line
Are we going to loop forever? From kernel side it looks ok. We are going
Quoted 8 lines
mark the path as failed.
Quoted 1 line
It depends on what the path checker from multipath is going to do. Do you
have any idea about it?
Good question. I'm not a multipath expert, but as far as I understand the multipath user space software if activating a path fails after some delay multipathd tries again to find a usable I/O path.
I was worried that path checker will somehow think the "unavailable state" as good. That might trigger continues path activations. But that is not the case. Tested with tur checker. It detects the state correctly. We are good. See below.
Jun 22 14:27:20 nilgiris multipathd: mpathg: sdh - tur checker reports path is down Jun 22 14:27:20 nilgiris kernel: sd 1:0:1:1: [sdh] Done: SUCCESS Jun 22 14:27:20 nilgiris kernel: sd 1:0:1:1: [sdh] Result: hostbyte=DID_OK driverbyte=DRIVER_OK Jun 22 14:27:20 nilgiris kernel: sd 1:0:1:1: [sdh] CDB: Test Unit Ready: 00 00 00 00 00 00 Jun 22 14:27:20 nilgiris kernel: sd 1:0:1:1: [sdh] Sense Key : Not Ready [current] Jun 22 14:27:20 nilgiris kernel: sd 1:0:1:1: [sdh] Add. Sense: Logical unit not accessible, target port in unavailable state
Patch looks good.
Quoted 2 lines
Bart.