Description of problem:
If multipathd(8) started, 'multipath -l' displays outdated
path check information from multipathd(8).
Version-Release number of selected component:
device-mapper-multipath-0.4.5-16.0.RHEL4
How reproducible:
Always
Steps to Reproduce:
1. Start multipathd.
# /etc/init.d/multipathd start
2. Create multipath map.
# multipath
3. do 'multipath -l'
# multipath -l
Actual results:
'multipath -l' displays outdated path check information from multipathd.
---------------------------------------------------------------------
disk1 (1NEC_____iStorage_2000___000000092680024600001)
[size=66 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 4:0:0:1 sdd 8:48 [active][ready]
\_ round-robin 0 [enabled]
\_ 5:0:0:1 sdh 8:112 [active][ready]
---------------------------------------------------------------------
Expected results:
'multipath -l' doesn't display outdated path check information.
---------------------------------------------------------------------
disk1 (1NEC_____iStorage_2000___000000092680024600001)
[size=66 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 4:0:0:1 sdd 8:48 [active]
\_ round-robin 0 [enabled]
\_ 5:0:0:1 sdh 8:112 [active]
---------------------------------------------------------------------
Additional info:
The '[ready]' is the information loaded from multipathd(8)
instead of self-checking.
So If multipathd has not recognized path status change yet,
it could be incorrect information.
To see path status, we should use 'multipath -ll' instead.
So 'multipath -l' doesn't need to display the information.
Attached patch fixed this problem by initializing pp->state of the cache.
This is not a regression.
Comment 3RHEL Program Management
2006-08-18 15:34:00 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
release.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHEA-2007-0256.html
Description of problem: If multipathd(8) started, 'multipath -l' displays outdated path check information from multipathd(8). Version-Release number of selected component: device-mapper-multipath-0.4.5-16.0.RHEL4 How reproducible: Always Steps to Reproduce: 1. Start multipathd. # /etc/init.d/multipathd start 2. Create multipath map. # multipath 3. do 'multipath -l' # multipath -l Actual results: 'multipath -l' displays outdated path check information from multipathd. --------------------------------------------------------------------- disk1 (1NEC_____iStorage_2000___000000092680024600001) [size=66 GB][features="1 queue_if_no_path"][hwhandler="0"] \_ round-robin 0 [active] \_ 4:0:0:1 sdd 8:48 [active][ready] \_ round-robin 0 [enabled] \_ 5:0:0:1 sdh 8:112 [active][ready] --------------------------------------------------------------------- Expected results: 'multipath -l' doesn't display outdated path check information. --------------------------------------------------------------------- disk1 (1NEC_____iStorage_2000___000000092680024600001) [size=66 GB][features="1 queue_if_no_path"][hwhandler="0"] \_ round-robin 0 [active] \_ 4:0:0:1 sdd 8:48 [active] \_ round-robin 0 [enabled] \_ 5:0:0:1 sdh 8:112 [active] --------------------------------------------------------------------- Additional info: The '[ready]' is the information loaded from multipathd(8) instead of self-checking. So If multipathd has not recognized path status change yet, it could be incorrect information. To see path status, we should use 'multipath -ll' instead. So 'multipath -l' doesn't need to display the information. Attached patch fixed this problem by initializing pp->state of the cache. This is not a regression.