<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> To all,<o:p></o:p> <o:p> </o:p> My colleague Menno tried the readsector0 setting and had better results but tur is still the preferred setting.<o:p></o:p> So we try to come to a solution with tur as a setting.<o:p></o:p> <o:p> </o:p> The official response about the (SVC) SCSI responses of IBM support you can find below.<o:p></o:p> We unmapped and mapped existing luns on a Linux server and IBM analyzed the SVC dump.<o:p></o:p> <o:p> </o:p> Can the solution be that there is an extra option where tur checks xx times if there is a SCSI check condition<o:p></o:p> and then reports the path down. This instead of reporting him down after one SCSI check condition.<o:p></o:p> <o:p> </o:p> From IBM support:<o:p></o:p> When the mappings change between a SVC and a host server, SVC will <o:p></o:p> always set a SCSI Unit Attention: "Reported Luns Data Has Changed". <o:p></o:p> This means the next SCSI command to arrive from the host for each <o:p></o:p> Initiator Port/Target Port/Vdisk combination will be failed with that <o:p></o:p> SCSI Check condition. This is the method by which SVC (as a passive <o:p></o:p> SCSI Target) can alert the host server (SCSI Initiator) that something <o:p></o:p> about the configuration has changed. <o:p></o:p> <o:p></o:p> In this case specifically, the host has 7 Vdisks mapped - then one is <o:p></o:p> unmapped. The next SCSI command (Test Unit Ready) to arrive at SVC for <o:p></o:p> each SCSI lun is failed as follows: The 6 to the still mapped luns are <o:p></o:p> failed with the SCSI Unit Attention: "Reported Luns Data Has Changed" <o:p></o:p> Check condition, and the one command to the now unmapped lun is failed <o:p></o:p> with a SCSI Check Condition: Illegal Request, "Logical Unit Not <o:p></o:p> Supported". <o:p></o:p> <o:p></o:p> Over the next minute or so, many more SCSI Test Unit Ready and Inquiry <o:p></o:p> (Page 0x83) commands are failed for the unmapped lun.<o:p></o:p> That is, the host continues to send commands so SCSI Lun 1, and SVC continues to fail them <o:p></o:p> with Check Condition: Illegal Request "Logical Unit Not Supported". <o:p></o:p> Then the Vdisk is mapped again, and SVC sets the SCSI Unit Attention: <o:p></o:p> Reported Luns Data Has Changed check condition again, which, again, <o:p></o:p> causes another set of commands to be failed to all luns - 7 commands in <o:p></o:p> total this time - one to each lun. <o:p></o:p> <o:p></o:p> Aside from the commands failed as described above, all other SCSI <o:p></o:p> commands (e.g. Test Unit Ready, Inquir, Maintenance In (with Sevice <o:p></o:p> Action: Report Target Port Groups)) complete promptly with Good status. <o:p></o:p> <o:p></o:p> This pattern repeats a couple more times - for vdisk 15 and then for <o:p></o:p> vdisk 14. <o:p></o:p> <o:p></o:p> Whether the Test Unit Ready commands succeed or are failed with the <o:p></o:p> Check conditions described above does not seem to make a difference to <o:p></o:p> the SVC response time - of the couple of thousand we have details for, <o:p></o:p> all except for 4 took less than 100us to complete. The 'slowest' 4 took <o:p></o:p> 1, 1.2, 1.4 and 6 ms to complete. <o:p></o:p> <o:p></o:p> SVC is working as designed here and nothing suspicious is found from <o:p></o:p> SVC side. We guess something about the check conditions <o:p></o:p> SVC is reporting when the mappings are changed is leading to the delay <o:p></o:p> on the host perhaps? <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p></o:p> Kind regards,<o:p></o:p> Chris <o:p></o:p> <o:p></o:p> <o:p> </o:p> <o:p></o:p> <o:p> </o:p> </div> </body> </html> ********************************************************************** 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 **********************************************************************