FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 07-23-2008, 05:00 PM
"Pradipmaya Maharana"
 
Default Losing paths

Could you please share the result of "multipath -v4".

Regards,
Pradipmaya.

On Wed, Jul 23, 2008 at 6:22 AM, Koehler, M - SPLXM
<Menno.Koehler@klm.com> wrote:
> Hello,
>
> Thanks for your respond, first I tried the multipathd -k reconfigure
> (and get a ok returned) and later when seen that it still was using tur
> we tried a reboot but with the same result.
>
> Kind regards,
>
> Menno
>
>
> -----Original Message-----
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, July 23, 2008 3:13 PM
> To: device-mapper development
> Subject: RE: [dm-devel] Losing paths
>
> Did you change multipath.conf and reboot the machine?
> if not reboot, what steps put the changed multipath.conf into effect
> for the 2145's (SVC) LUNs?
>
>
> --------------------------------------------------------
> This e-mail, including any attachments, may be confidential, privileged
> or otherwise legally protected. It is intended only for the addressee.
> If you received this e-mail in error or from someone who was not
> authorized to send it to you, do not disseminate, copy or otherwise use
> this e-mail or its attachments. Please notify the sender immediately by
> reply e-mail and delete the e-mail from your system.
>
>
> -----Original Message-----
>
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
> On Behalf Of Koehler, M - SPLXM
> Sent: Wednesday, July 23, 2008 8:34 AM
> To: device-mapper development
> Subject: RE: [dm-devel] Losing paths
>
> Greetings,
>
> We tried testing with path_checker readsector0 end directio but we get
> some strange behavior eg the checker used is always tur!!
> So if we create a device entry special for IBM 2145 and define as
> path_checker directio or readsector0 we still see in the message file
> tur messages:
>
> Jul 23 08:09:00 kl11071i multipathd: 65:0: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:16: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:32: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:48: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:80: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:96: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:112: tur checker reports path is
> down
>
>
> Oure multipath.conf file is:
>
> defaults {
> user_friendly_names yes
> }
>
> devices{
> device {
> vendor "IBM"
> product "2145"
> path_grouping_policy group_by_prio
> getuid_callout "/sbin/scsi_id -g -u -s"
> prio_callout "/sbin/mpath_prio_alua %d"
> path_checker readsector0
> failback immediate
> }
> }
>
> Did someone see this behavior before? Or are we doing something wrong?
> We are using device-mapper-multipath-0.4.5-27.el4_6.3 on a rhel4.6
> system.
>
> Kind regards,
> Menno
> ************************************************** ********************
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> ************************************************** ********************
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 07-23-2008, 05:02 PM
"Romanowski, John (OFT)"
 
Default Losing paths

this is a longshot, but try multipath -ll -v3 | more
and see if the devices are really seen as IBM 2145? or something else?

I have sles not RedHat, not sure of differences;
Do you know if mkinitrd put an older copy of multipath.conf into initrd?
try mkinitrd, zipl, reboot.

-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of Koehler, M - SPLXM
Sent: Wednesday, July 23, 2008 9:23 AM
To: device-mapper development
Subject: RE: [dm-devel] Losing paths

Hello,

Thanks for your respond, first I tried the multipathd -k reconfigure
(and get a ok returned) and later when seen that it still was using tur
we tried a reboot but with the same result.

Kind regards,

Menno


-----Original Message-----
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of Romanowski, John (OFT)
Sent: Wednesday, July 23, 2008 3:13 PM
To: device-mapper development
Subject: RE: [dm-devel] Losing paths

Did you change multipath.conf and reboot the machine?
if not reboot, what steps put the changed multipath.conf into effect
for the 2145's (SVC) LUNs?


--------------------------------------------------------
This e-mail, including any attachments, may be confidential, privileged
or otherwise legally protected. It is intended only for the addressee.
If you received this e-mail in error or from someone who was not
authorized to send it to you, do not disseminate, copy or otherwise use
this e-mail or its attachments. Please notify the sender immediately by
reply e-mail and delete the e-mail from your system.


-----Original Message-----

From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
On Behalf Of Koehler, M - SPLXM
Sent: Wednesday, July 23, 2008 8:34 AM
To: device-mapper development
Subject: RE: [dm-devel] Losing paths

Greetings,

We tried testing with path_checker readsector0 end directio but we get
some strange behavior eg the checker used is always tur!!
So if we create a device entry special for IBM 2145 and define as
path_checker directio or readsector0 we still see in the message file
tur messages:

Jul 23 08:09:00 kl11071i multipathd: 65:0: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:16: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:32: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:48: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:80: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:96: tur checker reports path is
down
Jul 23 08:09:00 kl11071i multipathd: 65:112: tur checker reports path is
down


Oure multipath.conf file is:

defaults {
user_friendly_names yes
}

devices{
device {
vendor "IBM"
product "2145"
path_grouping_policy group_by_prio
getuid_callout "/sbin/scsi_id -g -u -s"
prio_callout "/sbin/mpath_prio_alua %d"
path_checker readsector0
failback immediate
}
}

Did someone see this behavior before? Or are we doing something wrong?
We are using device-mapper-multipath-0.4.5-27.el4_6.3 on a rhel4.6
system.

Kind regards,
Menno
************************************************** ********************
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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


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



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 07-23-2008, 10:32 PM
Menno Koehler
 
Default Losing paths

Greetings, and thanks again for your response,

I just found a small but importent mistake in the multipath.conf file.
There was no space between devices and the accolade so "devices{" it
must be "devices {" so I just changed that and checked as you already
suppost with multipath -ll -v5 and see now that the path_checker is
changed from tur to readsector0.
I will reproduce the tests tomorrow and will let you know or readsector0
will solve this issue.

Kind regards,
Menno Koehler


On Wed, 2008-07-23 at 13:02 -0400, Romanowski, John (OFT) wrote:
> this is a longshot, but try multipath -ll -v3 | more
> and see if the devices are really seen as IBM 2145? or something else?
>
> I have sles not RedHat, not sure of differences;
> Do you know if mkinitrd put an older copy of multipath.conf into initrd?
> try mkinitrd, zipl, reboot.
>
> -----Original Message-----
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
> On Behalf Of Koehler, M - SPLXM
> Sent: Wednesday, July 23, 2008 9:23 AM
> To: device-mapper development
> Subject: RE: [dm-devel] Losing paths
>
> Hello,
>
> Thanks for your respond, first I tried the multipathd -k reconfigure
> (and get a ok returned) and later when seen that it still was using tur
> we tried a reboot but with the same result.
>
> Kind regards,
>
> Menno
>
>
> -----Original Message-----
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
> On Behalf Of Romanowski, John (OFT)
> Sent: Wednesday, July 23, 2008 3:13 PM
> To: device-mapper development
> Subject: RE: [dm-devel] Losing paths
>
> Did you change multipath.conf and reboot the machine?
> if not reboot, what steps put the changed multipath.conf into effect
> for the 2145's (SVC) LUNs?
>
>
> --------------------------------------------------------
> This e-mail, including any attachments, may be confidential, privileged
> or otherwise legally protected. It is intended only for the addressee.
> If you received this e-mail in error or from someone who was not
> authorized to send it to you, do not disseminate, copy or otherwise use
> this e-mail or its attachments. Please notify the sender immediately by
> reply e-mail and delete the e-mail from your system.
>
>
> -----Original Message-----
>
> From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com]
> On Behalf Of Koehler, M - SPLXM
> Sent: Wednesday, July 23, 2008 8:34 AM
> To: device-mapper development
> Subject: RE: [dm-devel] Losing paths
>
> Greetings,
>
> We tried testing with path_checker readsector0 end directio but we get
> some strange behavior eg the checker used is always tur!!
> So if we create a device entry special for IBM 2145 and define as
> path_checker directio or readsector0 we still see in the message file
> tur messages:
>
> Jul 23 08:09:00 kl11071i multipathd: 65:0: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:16: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:32: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:48: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:80: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:96: tur checker reports path is
> down
> Jul 23 08:09:00 kl11071i multipathd: 65:112: tur checker reports path is
> down
>
>
> Oure multipath.conf file is:
>
> defaults {
> user_friendly_names yes
> }
>
> devices{
> device {
> vendor "IBM"
> product "2145"
> path_grouping_policy group_by_prio
> getuid_callout "/sbin/scsi_id -g -u -s"
> prio_callout "/sbin/mpath_prio_alua %d"
> path_checker readsector0
> failback immediate
> }
> }
>
> Did someone see this behavior before? Or are we doing something wrong?
> We are using device-mapper-multipath-0.4.5-27.el4_6.3 on a rhel4.6
> system.
>
> Kind regards,
> Menno
> ************************************************** ********************
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
> ************************************************** ********************
> 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@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>
>
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
************************************************** ********************
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@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-26-2008, 07:33 AM
"Vardaris, C - SPLXM"
 
Default 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 ************************************************** ********************
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 07:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org