* Re: Losing paths
@ 2008-07-22 16:21 Daniel Keisling
2008-07-22 22:10 ` guy keren
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Keisling @ 2008-07-22 16:21 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 2718 bytes --]
FWIW, I have the same issue under an HP EVA8000. I'm not really certain if directio is a solution as I have only seen the tur checker being used with an EVA.
Daniel
---------------------------------------------------------------------------------------------
Date: Tue, 22 Jul 2008 16:55:27 +0200
From: Hannes Reinecke <hare@suse.de>
Subject: Re: [dm-devel] Losing paths
To: device-mapper development <dm-devel@redhat.com>
Message-ID: <4885F4DF.8010000@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi John,
Romanowski, John (OFT) wrote:
> Hi,
> We had similar problem last year using sles9 and SVC 4.2.0.2, as you describe: adding/deleting a LUN causes
> brief path failures for the host's remaining, unaffected LUNs.
>
> We were using tur checker and it turned out that while adding/deleting a LUN (and some other admin tasks)
> the SVC does not respond well to test-unit-ready tur requests; but it responds perfectly well to normal read
> commands. I opened IBM PMR 43118 on that if you want to ask the SVC folks about it.
>
> Workaround for us was to use readsector0 instead of tur as multipath path checker.
>
> Recent post here (see July 8, 2008) said multipath-tools is deprecating readsector0, and to use directio as
> path checker, but directio was said to be much slower than tur, implying tur was better replacement than
> directio for readsector0.
>
Only for those cases where no actual read-access is necessary.
> Not sure what deprecating readsector0 means for us SVC users.
>
It means you should be using directio there.
Thanks for the information, I'll see to have it included in SLES10.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
______________________________________________________________________
This email transmission and any documents, files or previous email
messages attached to it may contain information that is confidential or
legally privileged. If you are not the intended recipient or a person
responsible for delivering this transmission to the intended recipient,
you are hereby notified that you must not read this transmission and
that any disclosure, copying, printing, distribution or use of this
transmission is strictly prohibited. If you have received this transmission
in error, please immediately notify the sender by telephone or return email
and delete the original transmission and its attachments without reading
or saving in any manner.
[-- Attachment #1.2: Type: text/html, Size: 5084 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Losing paths
2008-07-22 16:21 Losing paths Daniel Keisling
@ 2008-07-22 22:10 ` guy keren
2008-07-23 6:25 ` Hannes Reinecke
0 siblings, 1 reply; 14+ messages in thread
From: guy keren @ 2008-07-22 22:10 UTC (permalink / raw)
To: device-mapper development
Does the 'tur' checker take into account unit-attention issues (i.e.
when the configuration of a SCSI device changes, the next command coming
from an afected initiator (not necessarily to the same LU) should be
failed with a 'check condition' error and a 'unit attention' sense code.
if the TUR checker sent a TUR right after the change and before another
read/write command was sent - it will be failed, and then the question
is, whether the lower-level driver retries the TUR command, or returns
an error. any idea?
--guy
Daniel Keisling wrote:
> FWIW, I have the same issue under an HP EVA8000. I'm not really certain
> if directio is a solution as I have only seen the tur checker being used
> with an EVA.
>
> Daniel
>
>
> ---------------------------------------------------------------------------------------------
> Date: Tue, 22 Jul 2008 16:55:27 +0200
> From: Hannes Reinecke <hare@suse.de <mailto:hare@suse.de>>
> Subject: Re: [dm-devel] Losing paths
> To: device-mapper development <dm-devel@redhat.com
> <mailto:dm-devel@redhat.com>>
> Message-ID: <4885F4DF.8010000@suse.de <mailto:4885F4DF.8010000@suse.de>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi John,
>
> Romanowski, John (OFT) wrote:
>> Hi,
>> We had similar problem last year using sles9 and SVC 4.2.0.2, as you
> describe: adding/deleting a LUN causes
>> brief path failures for the host's remaining, unaffected LUNs.
>>
>> We were using tur checker and it turned out that while adding/deleting
> a LUN (and some other admin tasks)
>> the SVC does not respond well to test-unit-ready tur requests; but it
> responds perfectly well to normal read
>> commands. I opened IBM PMR 43118 on that if you want to ask the SVC
> folks about it.
>>
>> Workaround for us was to use readsector0 instead of tur as multipath
> path checker.
>>
>> Recent post here (see July 8, 2008) said multipath-tools is
> deprecating readsector0, and to use directio as
>> path checker, but directio was said to be much slower than tur,
> implying tur was better replacement than
>> directio for readsector0.
>>
> Only for those cases where no actual read-access is necessary.
>
>> Not sure what deprecating readsector0 means for us SVC users.
>>
> It means you should be using directio there.
>
> Thanks for the information, I'll see to have it included in SLES10.
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke zSeries & Storage
> hare@suse.de <mailto:hare@suse.de> +49 911 74053 688
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: Markus Rex, HRB 16746 (AG Nürnberg)
>
>
>
>
> ______________________________________________________________________
> This email transmission and any documents, files or previous email
> messages attached to it may contain information that is confidential or
> legally privileged. If you are not the intended recipient or a person
> responsible for delivering this transmission to the intended recipient,
> you are hereby notified that you must not read this transmission and
> that any disclosure, copying, printing, distribution or use of this
> transmission is strictly prohibited. If you have received this transmission
> in error, please immediately notify the sender by telephone or return email
> and delete the original transmission and its attachments without reading
> or saving in any manner.
>
>
> ------------------------------------------------------------------------
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Losing paths
2008-07-22 22:10 ` guy keren
@ 2008-07-23 6:25 ` Hannes Reinecke
0 siblings, 0 replies; 14+ messages in thread
From: Hannes Reinecke @ 2008-07-23 6:25 UTC (permalink / raw)
To: device-mapper development
Hi Guy,
guy keren wrote:
>
> Does the 'tur' checker take into account unit-attention issues (i.e.
> when the configuration of a SCSI device changes, the next command coming
> from an afected initiator (not necessarily to the same LU) should be
> failed with a 'check condition' error and a 'unit attention' sense code.
>
> if the TUR checker sent a TUR right after the change and before another
> read/write command was sent - it will be failed, and then the question
> is, whether the lower-level driver retries the TUR command, or returns
> an error. any idea?
>
It does for SLES10 SP2. Upstream not; I'll have to send the
patches one day.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Losing paths
@ 2008-08-26 7:33 Vardaris, C - SPLXM
0 siblings, 0 replies; 14+ messages in thread
From: Vardaris, C - SPLXM @ 2008-08-26 7:33 UTC (permalink / raw)
To: device-mapper development
[-- Attachment #1.1: Type: text/plain, Size: 4435 bytes --]
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
**********************************************************************
[-- Attachment #1.2: Type: text/html, Size: 20431 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Losing paths
@ 2008-07-22 11:22 Vardaris, C - SPLXM
2008-07-22 14:44 ` Romanowski, John (OFT)
0 siblings, 1 reply; 14+ messages in thread
From: Vardaris, C - SPLXM @ 2008-07-22 11:22 UTC (permalink / raw)
To: dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 22650 bytes --]
To all,
Is it normal DM behavior that we are (temporary) losing paths from
'unaffected' LUN's when we unmap a SAN LUN from the storage side.
We are using an IBM SVC (4.2.1) and RH AS 4.6. We are using the
multipath.conf file supplied by IBM for the SVC.
It's normal that you loose the paths of the LUN which you unmap (4 paths
in our case), but why we are also losing paths from 'unaffected' LUN's.
Unmapping a LUN is not a normal storage admin action but could happen
accidentally.
We also see the same behavior when we give a new LUN to the Linux
server. The minute we map the LUN, paths from other LUN's are
temporarily disappearing.
We tried several settings/HBA firmware etc. but can not eliminate this
behavior of DM.
Jul 2 13:36:54 kl1108ju multipathd: 65:176: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:176 in map
360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:176.
Jul 2 13:36:54 kl1108ju multipathd: 65:192: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:192 in map
360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:192.
Jul 2 13:36:54 kl1108ju multipathd: 65:208: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:208 in map
360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:208.
Jul 2 13:36:54 kl1108ju multipathd: 65:240: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:240 in map
360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:240.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju multipathd: 67:0: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:0 in map
360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:0.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju multipathd: 67:32: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:32 in map
360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:32.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:48.
Jul 2 13:36:54 kl1108ju multipathd: 67:48: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:64.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:48 in map
360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:80.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:96.
Jul 2 13:36:54 kl1108ju multipathd: 67:64: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:112.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:64 in map
360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:128.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:160.
Jul 2 13:36:54 kl1108ju multipathd: 67:80: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:176.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:80 in map
360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:192.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:208.
Jul 2 13:36:54 kl1108ju multipathd: 67:96: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:224.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:96 in map
360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 67:240.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:0.
Jul 2 13:36:54 kl1108ju multipathd: 67:112: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:32.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:112 in map
360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:48.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:64.
Jul 2 13:36:54 kl1108ju multipathd: 67:128: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:80.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:128 in map
360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:96.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:112.
Jul 2 13:36:54 kl1108ju multipathd: 67:160: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing
path 65:128.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:160 in map
360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju multipathd: 67:176: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:176 in map
360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:192: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:192 in map
360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:208: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:208 in map
360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:224: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:224 in map
360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 2
Jul 2 13:36:54 kl1108ju multipathd: 67:240: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:240 in map
360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:0: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:0 in map
360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:32: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:32 in map
360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:48: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:48 in map
360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:64: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:64 in map
360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:80: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:80 in map
360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:96: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:96 in map
360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:112: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:112 in map
360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:128: tur checker reports path is
down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:128 in map
360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
Entering recovery mode: max_retries=5
Jul 2 13:36:55 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
Entering recovery mode: max_retries=5
Jul 2 13:37:24 kl1108ju multipathd: 65:176: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 65:176: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 65:192: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 65:192: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 65:208: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 65:208: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 65:240: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 65:240: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 67:0: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:0: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 67:32: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:32: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:48: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:48: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:64: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:64: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:80: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:80: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:96: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:96: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:112: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:112: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:128: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:128: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:160: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:160: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:176: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:176: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:192: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:192: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 67:208: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:208: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 67:224: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:224: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:240: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 67:240: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 65:0: tur checker reports path is
up
Jul 2 13:37:24 kl1108ju multipathd: 65:0: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0:
remaining active paths: 3
Jul 2 13:37:25 kl1108ju multipathd: 65:32: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:32: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001ce:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:48: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:48: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d2:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:64: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:64: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d3:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:80: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:80: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f800000000000354:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:96: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:96: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d4:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:112: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:112: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d1:
remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:128: tur checker reports path is
up
Jul 2 13:37:25 kl1108ju multipathd: 65:128: reinstated
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
**********************************************************************
[-- Attachment #1.2: Type: text/html, Size: 50588 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Losing paths
2008-07-22 11:22 Vardaris, C - SPLXM
@ 2008-07-22 14:44 ` Romanowski, John (OFT)
2008-07-22 14:55 ` Hannes Reinecke
2008-07-23 8:44 ` Vardaris, C - SPLXM
0 siblings, 2 replies; 14+ messages in thread
From: Romanowski, John (OFT) @ 2008-07-22 14:44 UTC (permalink / raw)
To: device-mapper development
Hi,
We had similar problem last year using sles9 and SVC 4.2.0.2, as you describe: adding/deleting a LUN causes brief path failures for the host's remaining, unaffected LUNs.
We were using tur checker and it turned out that while adding/deleting a LUN (and some other admin tasks) the SVC does not respond well to test-unit-ready tur requests; but it responds perfectly well to normal read commands. I opened IBM PMR 43118 on that if you want to ask the SVC folks about it.
Workaround for us was to use readsector0 instead of tur as multipath path checker.
Recent post here (see July 8, 2008) said multipath-tools is deprecating readsector0, and to use directio as path checker, but directio was said to be much slower than tur, implying tur was better replacement than directio for readsector0.
Not sure what deprecating readsector0 means for us SVC users.
regards,
John
--------------------------------------------------------
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.
________________________________________
From: dm-devel-bounces@redhat.com [mailto:dm-devel-bounces@redhat.com] On Behalf Of Vardaris, C - SPLXM
Sent: Tuesday, July 22, 2008 7:23 AM
To: dm-devel@redhat.com
Subject: [dm-devel] Losing paths
To all,
Is it normal DM behavior that we are (temporary) losing paths from 'unaffected' LUN's when we unmap a SAN LUN from the storage side.
We are using an IBM SVC (4.2.1) and RH AS 4.6. We are using the multipath.conf file supplied by IBM for the SVC.
It's normal that you loose the paths of the LUN which you unmap (4 paths in our case), but why we are also losing paths from 'unaffected' LUN's.
Unmapping a LUN is not a normal storage admin action but could happen accidentally.
We also see the same behavior when we give a new LUN to the Linux server. The minute we map the LUN, paths from other LUN's are temporarily disappearing.
We tried several settings/HBA firmware etc. but can not eliminate this behavior of DM.
Jul 2 13:36:54 kl1108ju multipathd: 65:176: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:176 in map 360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:176.
Jul 2 13:36:54 kl1108ju multipathd: 65:192: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:192 in map 360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:192.
Jul 2 13:36:54 kl1108ju multipathd: 65:208: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:208 in map 360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:208.
Jul 2 13:36:54 kl1108ju multipathd: 65:240: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:240 in map 360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:240.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 3
Jul 2 13:36:54 kl1108ju multipathd: 67:0: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:0 in map 360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:0.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 3
Jul 2 13:36:54 kl1108ju multipathd: 67:32: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:32 in map 360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:32.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:48.
Jul 2 13:36:54 kl1108ju multipathd: 67:48: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:64.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:48 in map 360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:80.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:96.
Jul 2 13:36:54 kl1108ju multipathd: 67:64: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:112.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:64 in map 360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:128.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:160.
Jul 2 13:36:54 kl1108ju multipathd: 67:80: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:176.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:80 in map 360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:192.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:208.
Jul 2 13:36:54 kl1108ju multipathd: 67:96: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:224.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:96 in map 360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 67:240.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 3
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:0.
Jul 2 13:36:54 kl1108ju multipathd: 67:112: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:32.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:112 in map 360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:48.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:64.
Jul 2 13:36:54 kl1108ju multipathd: 67:128: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:80.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:128 in map 360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:96.
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 2
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:112.
Jul 2 13:36:54 kl1108ju multipathd: 67:160: tur checker reports path is down
Jul 2 13:36:54 kl1108ju kernel: device-mapper: dm-multipath: Failing path 65:128.
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:160 in map 360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 2
Jul 2 13:36:54 kl1108ju multipathd: 67:176: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:176 in map 360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:192: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:192 in map 360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:208: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:208 in map 360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 67:224: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:224 in map 360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 2
Jul 2 13:36:54 kl1108ju multipathd: 67:240: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 67:240 in map 360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:0: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:0 in map 360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:32: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:32 in map 360050768018180a4f8000000000001ce
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:48: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:48 in map 360050768018180a4f8000000000001d2
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:64: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:64 in map 360050768018180a4f8000000000001d3
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:80: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:80 in map 360050768018180a4f800000000000354
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:96: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:96 in map 360050768018180a4f8000000000001d4
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 1
Jul 2 13:36:54 kl1108ju multipathd: 65:112: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:112 in map 360050768018180a4f8000000000001d1
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 65:128: tur checker reports path is down
Jul 2 13:36:54 kl1108ju multipathd: checker failed path 65:128 in map 360050768018180a4f8000000000001d0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 0
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d2: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d3: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f800000000000354: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d0: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: Entering recovery mode: max_retries=5
Jul 2 13:36:54 kl1108ju multipathd: 360050768018180a4f8000000000001d1: Entering recovery mode: max_retries=5
Jul 2 13:36:55 kl1108ju multipathd: 360050768018180a4f8000000000001d0: Entering recovery mode: max_retries=5
Jul 2 13:37:24 kl1108ju multipathd: 65:176: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 65:176: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2: queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2: Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 65:192: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 65:192: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 65:208: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 65:208: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 65:240: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 65:240: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: switch to path group #2
Jul 2 13:37:24 kl1108ju multipathd: 67:0: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:0: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0: queue_if_no_path enabled
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0: Recovered to normal mode
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 1
Jul 2 13:37:24 kl1108ju multipathd: 67:32: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:32: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:48: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:48: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:64: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:64: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:80: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:80: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:96: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:96: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:112: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:112: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:128: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:128: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 2
Jul 2 13:37:24 kl1108ju multipathd: 67:160: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:160: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:176: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:176: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:192: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:192: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d3: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 67:208: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:208: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f800000000000354: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 67:224: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:224: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 67:240: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 67:240: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 3
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d1: switch to path group #1
Jul 2 13:37:24 kl1108ju multipathd: 65:0: tur checker reports path is up
Jul 2 13:37:24 kl1108ju multipathd: 65:0: reinstated
Jul 2 13:37:24 kl1108ju multipathd: 360050768018180a4f8000000000001d0: remaining active paths: 3
Jul 2 13:37:25 kl1108ju multipathd: 65:32: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:32: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001ce: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:48: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:48: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d2: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:64: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:64: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d3: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:80: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:80: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f800000000000354: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:96: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:96: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d4: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:112: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:112: reinstated
Jul 2 13:37:25 kl1108ju multipathd: 360050768018180a4f8000000000001d1: remaining active paths: 4
Jul 2 13:37:25 kl1108ju multipathd: 65:128: tur checker reports path is up
Jul 2 13:37:25 kl1108ju multipathd: 65:128: reinstated
Kind regards,
Chris
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Losing paths
2008-07-22 14:44 ` Romanowski, John (OFT)
@ 2008-07-22 14:55 ` Hannes Reinecke
2008-07-23 8:44 ` Vardaris, C - SPLXM
1 sibling, 0 replies; 14+ messages in thread
From: Hannes Reinecke @ 2008-07-22 14:55 UTC (permalink / raw)
To: device-mapper development
Hi John,
Romanowski, John (OFT) wrote:
> Hi,
> We had similar problem last year using sles9 and SVC 4.2.0.2, as you describe: adding/deleting a LUN causes
> brief path failures for the host's remaining, unaffected LUNs.
>
> We were using tur checker and it turned out that while adding/deleting a LUN (and some other admin tasks)
> the SVC does not respond well to test-unit-ready tur requests; but it responds perfectly well to normal read
> commands. I opened IBM PMR 43118 on that if you want to ask the SVC folks about it.
>
> Workaround for us was to use readsector0 instead of tur as multipath path checker.
>
> Recent post here (see July 8, 2008) said multipath-tools is deprecating readsector0, and to use directio as
> path checker, but directio was said to be much slower than tur, implying tur was better replacement than
> directio for readsector0.
>
Only for those cases where no actual read-access is necessary.
> Not sure what deprecating readsector0 means for us SVC users.
>
It means you should be using directio there.
Thanks for the information, I'll see to have it included in SLES10.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Losing paths
2008-07-22 14:44 ` Romanowski, John (OFT)
2008-07-22 14:55 ` Hannes Reinecke
@ 2008-07-23 8:44 ` Vardaris, C - SPLXM
2008-07-23 12:33 ` Koehler, M - SPLXM
1 sibling, 1 reply; 14+ messages in thread
From: Vardaris, C - SPLXM @ 2008-07-23 8:44 UTC (permalink / raw)
To: device-mapper development
Greetings,
Thanks for all the input so far.
This afternoon we are going to test with directio, but is this an
usable/reliable setting in a Linux cluster environment?
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
**********************************************************************
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Losing paths
2008-07-23 8:44 ` Vardaris, C - SPLXM
@ 2008-07-23 12:33 ` Koehler, M - SPLXM
2008-07-23 13:12 ` Romanowski, John (OFT)
0 siblings, 1 reply; 14+ messages in thread
From: Koehler, M - SPLXM @ 2008-07-23 12:33 UTC (permalink / raw)
To: device-mapper development
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
**********************************************************************
^ permalink raw reply [flat|nested] 14+ messages in thread* RE: Losing paths
2008-07-23 12:33 ` Koehler, M - SPLXM
@ 2008-07-23 13:12 ` Romanowski, John (OFT)
2008-07-23 13:22 ` Koehler, M - SPLXM
0 siblings, 1 reply; 14+ messages in thread
From: Romanowski, John (OFT) @ 2008-07-23 13:12 UTC (permalink / raw)
To: device-mapper development
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
^ permalink raw reply [flat|nested] 14+ messages in thread* RE: Losing paths
2008-07-23 13:12 ` Romanowski, John (OFT)
@ 2008-07-23 13:22 ` Koehler, M - SPLXM
2008-07-23 17:00 ` Pradipmaya Maharana
2008-07-23 17:02 ` Romanowski, John (OFT)
0 siblings, 2 replies; 14+ messages in thread
From: Koehler, M - SPLXM @ 2008-07-23 13:22 UTC (permalink / raw)
To: device-mapper development
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
**********************************************************************
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Losing paths
2008-07-23 13:22 ` Koehler, M - SPLXM
@ 2008-07-23 17:00 ` Pradipmaya Maharana
2008-07-23 17:02 ` Romanowski, John (OFT)
1 sibling, 0 replies; 14+ messages in thread
From: Pradipmaya Maharana @ 2008-07-23 17:00 UTC (permalink / raw)
To: device-mapper development
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread* RE: Losing paths
2008-07-23 13:22 ` Koehler, M - SPLXM
2008-07-23 17:00 ` Pradipmaya Maharana
@ 2008-07-23 17:02 ` Romanowski, John (OFT)
2008-07-23 22:32 ` Menno Koehler
1 sibling, 1 reply; 14+ messages in thread
From: Romanowski, John (OFT) @ 2008-07-23 17:02 UTC (permalink / raw)
To: device-mapper development
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
^ permalink raw reply [flat|nested] 14+ messages in thread* RE: Losing paths
2008-07-23 17:02 ` Romanowski, John (OFT)
@ 2008-07-23 22:32 ` Menno Koehler
0 siblings, 0 replies; 14+ messages in thread
From: Menno Koehler @ 2008-07-23 22:32 UTC (permalink / raw)
To: device-mapper development
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
**********************************************************************
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-08-26 7:33 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-22 16:21 Losing paths Daniel Keisling
2008-07-22 22:10 ` guy keren
2008-07-23 6:25 ` Hannes Reinecke
-- strict thread matches above, loose matches on Subject: below --
2008-08-26 7:33 Vardaris, C - SPLXM
2008-07-22 11:22 Vardaris, C - SPLXM
2008-07-22 14:44 ` Romanowski, John (OFT)
2008-07-22 14:55 ` Hannes Reinecke
2008-07-23 8:44 ` Vardaris, C - SPLXM
2008-07-23 12:33 ` Koehler, M - SPLXM
2008-07-23 13:12 ` Romanowski, John (OFT)
2008-07-23 13:22 ` Koehler, M - SPLXM
2008-07-23 17:00 ` Pradipmaya Maharana
2008-07-23 17:02 ` Romanowski, John (OFT)
2008-07-23 22:32 ` Menno Koehler
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.