Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1397090

Summary: [NetApp 7.2 Bug]: Tur path_checker reports path status as UP in message file when paths are in failed state
Product: Red Hat Enterprise Linux 7 Reporter: Abhishek Kumar <abhishek.kumar4>
Component: device-mapper-multipathAssignee: Ben Marzinski <bmarzins>
Status: CLOSED DUPLICATE QA Contact: Storage QE <storage-qe>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.2CC: abhishek.kumar4, agk, akarlsso, bgoncalv, bmarzins, coughlan, ctatman, gowrav.mahadevaiah, heinzm, msnitzer, prajnoha, xdl-redhat-bugzilla
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-29 23:39:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Abhishek Kumar 2016-11-21 15:18:13 UTC
Description of problem:

With GA kernel of RHEL7.2 we have observed that tur path_checker reporting path as UP in messages file even when the path is in failed faulty state.

from below messages file we observe that tur path_checker reporting paths as up but multipath output clearly shows that those paths are in failed faulty state.
 
from /var/log/messages:

Feb 29 16:56:06 ibmx3650m4-210-145 multipathd: 3600a09803830344674244644694e6e76: sdac - tur checker reports path is up 

Feb 29 16:56:06 ibmx3650m4-210-145 multipathd: 3600a09803830344674244644694e6e79: sdaf - tur checker reports path is up 

Feb 29 16:56:06 ibmx3650m4-210-145 multipathd: 3600a0980383034444824464c59386466: sdap - tur checker reports path is up 

Feb 29 16:56:06 ibmx3650m4-210-145 multipathd: 3600a0980383034444824464c59386467: sdaq - tur checker reports path is up

[root@ibmx3650m4-210-145 ~]# multipath -ll | grep sdac
   |- 0:0:7:20  sdac  65:192  failed faulty running
[root@ibmx3650m4-210-145 ~]#
[root@ibmx3650m4-210-145 ~]# multipath -ll | grep sdaf
   |- 0:0:7:23  sdaf  65:240  failed faulty running
[root@ibmx3650m4-210-145 ~]# multipath -ll | grep sdap
   |- 0:0:7:33  sdap  66:144  failed faulty running
[root@ibmx3650m4-210-145 ~]# multipath -ll | grep sdaq
   |- 0:0:7:34  sdaq  66:160  failed faulty running

Feb 29 16:54:26 ibmx3650m4-210-144 multipathd: 3600a0980383034444824464c59386461: sdan - tur checker reports path is up 

Feb 29 16:54:26 ibmx3650m4-210-144 multipathd: 3600a0980383034444824464c59386462: sdao - tur checker reports path is up 

Feb 29 16:54:26 ibmx3650m4-210-144 multipathd: 3600a09803830345877244644686c4e4d: sdf - tur checker reports path is up 

Feb 29 16:54:26 ibmx3650m4-210-144 multipathd: 3600a09803830344674244644694e6f6c: sdap - tur checker reports path is up 

Feb 29 16:54:26 ibmx3650m4-210-144 multipathd:  3600a09803830345877244644686c4f4f: sdas - tur checker reports path is up


[root@ibmx3650m4-210-144 ~]# multipath -ll | grep -i sdan
   |- 1:0:1:38  sdan  66:112  failed faulty running
[root@ibmx3650m4-210-144 ~]# multipath -ll | grep -i sdao
   |- 1:0:1:39  sdao  66:128  failed faulty running
[root@ibmx3650m4-210-144 ~]# multipath -ll | grep -i sdf
| |- 1:0:1:4   sdf   8:80    failed faulty running
[root@ibmx3650m4-210-144 ~]# multipath -ll | grep -i sdap
   |- 1:0:1:40  sdap  66:144  failed faulty running
[root@ibmx3650m4-210-144 ~]# multipath -ll | grep -i sdas
| `- 1:0:1:43  sdas  66:192  failed faulty running




Version-Release number of selected component (if applicable):

OS - RHEL 7.2 
How reproducible:


Steps to Reproduce:
1. Install RHEL7U2 on a SAN LUN
2. Map 40 LUN and configure DMMP and LV on all LUNs 
3. Create EXT4 and XFS file systems on LVs, and mount them 
4. Start IO to all mount points 
5. Start storage faults on the controllers 
6. while Storage node goes down eventually paths coming from that node also goes down but still tur path_checker reports path as UP


Actual results:

Tur path_checker reports path as up for failed faulty path


Expected results:

Tur path_checker should report path as down for failed faulty path
Additional info:

Comment 1 Ben Marzinski 2016-11-21 15:48:19 UTC
Can you please see if this is reproducible with the RHEL-7.3 device-mapper-multipath code.  I believe that this issue has been fixed in device-mapper-multipath-0.4.9-87.el7 and later by the changes for Bug 1280524.

Comment 2 Abhishek Kumar 2016-11-22 11:50:22 UTC
i dint see this issue with RHEL7.3 GA.

we don't have access to Bug 1280524.can you please provide the access?

Comment 4 Ben Marzinski 2016-11-29 23:30:39 UTC
You should have access to Bug 1280524 now.

Comment 5 Ben Marzinski 2016-11-29 23:39:55 UTC

*** This bug has been marked as a duplicate of bug 1280524 ***