[PATCH] scsi_dh_alua: Re-enable STPG for unavailable ports

[PATCH] scsi_dh_alua: Re-enable STPG for unavailable ports

[Bart Van Assche]

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.

Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Babu Moger <babu.moger@netapp.com>
Cc: Hannes Reinecke <hare@suse.de>

---
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(-)

diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
index 5088209..155fadc 100644
--- a/drivers/scsi/device_handler/scsi_dh_alua.c
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c
@@ -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;

RE: [PATCH] scsi_dh_alua: Re-enable STPG for unavailable ports

[Moger, Babu]

Bart,

> -----Original Message-----
> From: Bart Van Assche [mailto:bvanassche@acm.org]
> 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 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.

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?

> 
> Signed-off-by: Bart Van Assche <bvanassche@acm.org>
> Cc: Babu Moger <babu.moger@netapp.com>
> Cc: Hannes Reinecke <hare@suse.de>
> 
> ---
> 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(-)
> 
> diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c
> b/drivers/scsi/device_handler/scsi_dh_alua.c
> index 5088209..155fadc 100644
> --- a/drivers/scsi/device_handler/scsi_dh_alua.c
> +++ b/drivers/scsi/device_handler/scsi_dh_alua.c
> @@ -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;

Re: [PATCH] scsi_dh_alua: Re-enable STPG for unavailable ports

[Bart Van Assche]

On 06/22/12 17:52, Moger, Babu wrote:

> 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.

RE: [PATCH] scsi_dh_alua: Re-enable STPG for unavailable ports

[Moger, Babu]

> -----Original Message-----
> From: Bart Van Assche [mailto:bvanassche@acm.org]
> 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 ports
> 
> On 06/22/12 17:52, Moger, Babu wrote:
> 
> > 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.

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.

Reviewed-by: Babu Moger <babu.moger@netapp.com> 

> 
> Bart.