[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Losing paths



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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]