[dm-devel] Losing paths

Tue Aug 26 07:33:16 UTC 2008

To all,

My colleague Menno tried the readsector0 setting and had better results
but tur is still the preferred setting.

So we try to come to a solution with tur as a setting.

The official response about the (SVC) SCSI responses of IBM support you
can find below.

We unmapped and mapped existing luns on a Linux server and IBM analyzed
the SVC dump.

Can the solution be that there is an extra option where tur checks xx
times if there is a SCSI check condition

and then reports the path down. This instead of reporting him down after
one SCSI check condition.

From IBM support:

When the mappings change between a SVC and a host server, SVC will

always set a SCSI Unit Attention:  "Reported Luns Data Has Changed".

This means the next SCSI command to arrive from the host for each

Initiator Port/Target Port/Vdisk combination will be failed with that

SCSI Check condition.  This is the method by which SVC (as a passive

SCSI Target) can alert the host server (SCSI Initiator) that something

about the configuration has changed.

In this case specifically, the host has 7 Vdisks mapped - then one is

unmapped.  The next SCSI command (Test Unit Ready) to arrive at SVC for

each SCSI lun is failed as follows:  The 6 to the still mapped luns are

failed with the SCSI Unit Attention:  "Reported Luns Data Has Changed"

Check condition, and the one command to the now unmapped lun is failed

with a SCSI Check Condition:  Illegal Request, "Logical Unit Not

Supported".

Over the next minute or so, many more SCSI Test Unit Ready and Inquiry

(Page 0x83) commands are failed for the unmapped lun.

That is, the host continues to send commands so SCSI Lun 1, and SVC
continues to fail them  

with Check Condition:  Illegal Request "Logical Unit Not Supported".

Then the Vdisk is mapped again, and SVC sets the SCSI Unit Attention:

Reported Luns Data Has Changed check condition again, which, again,

causes another set of commands to be failed to all luns - 7 commands in

total this time - one to each lun.

Aside from the commands failed as described above, all other SCSI

commands (e.g.  Test Unit Ready, Inquir, Maintenance In (with Sevice

Action:  Report Target Port Groups)) complete promptly with Good status.

This pattern repeats a couple more times - for vdisk 15 and then for

vdisk 14.

Whether the Test Unit Ready commands succeed or are failed with the

Check conditions described above does not seem to make a difference to

the SVC response time - of the couple of thousand we have details for,

all except for 4 took less than 100us to complete.  The 'slowest' 4 took

1, 1.2, 1.4 and 6 ms to complete.

SVC is working as designed here and nothing suspicious is found from

SVC side. We guess something about the check conditions

SVC is reporting when the mappings are changed is leading to the delay

on the host perhaps?

Kind regards,

Chris 

**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286 
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20080826/ad9fd57d/attachment.htm>