Losing paths

Losing paths

[Vardaris, C - SPLXM]

[-- 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 --]

RE: Losing paths

[Romanowski, John (OFT)]

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

Re: Losing paths

[Hannes Reinecke]

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)

RE: Losing paths

[Vardaris, C - SPLXM]

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

RE: Losing paths

[Koehler, M - SPLXM]

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

RE: Losing paths

[Romanowski, John (OFT)]

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

RE: Losing paths

[Koehler, M - SPLXM]

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

Re: Losing paths

[Pradipmaya Maharana]

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
>

RE: Losing paths

[Romanowski, John (OFT)]

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

RE: Losing paths

[Menno Koehler]

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

Re: Losing paths

[Daniel Keisling]

[-- 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 --]

Re: Losing paths

[guy keren]

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

Re: Losing paths

[Hannes Reinecke]

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)

Losing paths

[Vardaris, C - SPLXM]

[-- 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 --]