|
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 ********************************************************************** |
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
