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