Bug 716471 - sysfs fc_transport node_name is incorrect
Summary: sysfs fc_transport node_name is incorrect
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: device-mapper-multipath
Version: 5.6
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Mike Christie
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-24 15:07 UTC by Dave Sullivan
Modified: 2012-06-27 09:40 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-27 09:40:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
show clariion sp mappings to mpio paths when running multipath -l (3.49 KB, application/x-shellscript)
2011-06-24 15:07 UTC, Dave Sullivan
no flags Details
navisecli dump (1.12 MB, text/plain)
2011-06-24 15:08 UTC, Dave Sullivan
no flags Details

Description Dave Sullivan 2011-06-24 15:07:05 UTC
Created attachment 509785 [details]
show clariion sp mappings to mpio paths when running multipath -l

Description of problem:

Another thing that I noticed is the node_name is not right
         [root@ustchscaeflx11 ~]# for i in `ls /sys/class/fc_transport`; do
    cat /sys/class/fc_transport/$i/node_name ; done
    0x50060160c6e01b7b
    0x50060160c6e01b7b
    0x50060160c6e01b7b
    0x50060160c6e01b7b

    I used navisecli command to pull this below, it would seem that the SP UID
    matches the node_name, but as you can see show as being the same and they
    should be unique

     P Name:             SP B
    SP Port ID:          7
    SP UID:              50:06:01:60:C6:E0:1B:7B:50:06:01:6F:46:E0:1B:7B
    SP Source ID:        2621440
    SP Name:             SP B
    SP Port ID:          6
    SP UID:              50:06:01:60:C6:E0:1B:7B:50:06:01:6E:46:E0:1B:7B
    SP Name:             SP B
    SP Port ID:          0
    SP UID:              50:06:01:60:C6:E0:1B:7B:50:06:01:68:46:E0:1B:7B
    SP Source ID:        655872
    SP Name:             SP B
    SP Port ID:          5
    SP UID:              50:06:01:60:C6:E0:1B:7B:50:06:01:6D:46:E0:1B:7B
    SP Source ID:        1310976
    SP Name:             SP B
    SP Port ID:          1
    SP UID:              50:06:01:60:C6:E0:1B:7B:50:06:01:69:46:E0:1B:7B
    SP Source ID:        1311232

    This was a Clariion CX-240

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


How reproducible:

Run the for loop above to print the /sys node_name for the fc_transports.

/opt/Navisphere/bin/naviseccli -h emcBspA getall > /tmp/emcB.txt

From this information you can locate the right SP, by looking at the SP Source ID that matches the /sys/class/fc_transport/<target>/port_id

just have to convert it to decimal


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Added two attachments one is a script that uses the navisecli dump to make multipath show the SP information that the paths align too.

Comment 1 Dave Sullivan 2011-06-24 15:08:14 UTC
Created attachment 509786 [details]
navisecli dump

Comment 2 Mike Christie 2011-06-24 18:55:34 UTC
Do you have 4 paths to the same target/node? I mean for each path to the same target/node you will get a different $i (scsi layer target id) in /sys/class/fc_transport/$i/node_name but each path will have the same node_name. Each path ends up going to the same node/target so that name will be the same, but the scsi layer in linux creates different scsi-ml target struct (and each struct gets a sysfs object) so you get different target id values for each path.

Hey, on a side note you should use the /sys/class/fc_remote_port dir instead of the fc_transport one. The fc_transport class/dir is removed in rhel 6.

Do you have multiple target/node instances setup on the target box and if so is it setup so the initiator can see all 4 targets/nodes? The script output had 4 items but the navi info had 5.

Comment 3 Dave Sullivan 2011-07-11 17:39:18 UTC
(In reply to comment #2)
> Do you have 4 paths to the same target/node? I mean for each path to the same
> target/node you will get a different $i (scsi layer target id) in
> /sys/class/fc_transport/$i/node_name but each path will have the same
> node_name. Each path ends up going to the same node/target so that name will be
> the same, but the scsi layer in linux creates different scsi-ml target struct
> (and each struct gets a sysfs object) so you get different target id values for
> each path.
> 
> Hey, on a side note you should use the /sys/class/fc_remote_port dir instead of
> the fc_transport one. The fc_transport class/dir is removed in rhel 6.
> 
> Do you have multiple target/node instances setup on the target box and if so is
> it setup so the initiator can see all 4 targets/nodes? The script output had 4
> items but the navi info had 5.

Ok, so node_name is really just the identifier for the clariion, not an individual SP UID.  That makes sense then that it would be the same (so definitely no bug).  Is the SP UID (pulled from the navisecli dump), which really looks like a unique SP Port UUID maintained anywhere under /sysfs.  I don't see it.

Here's a mapping that I made and you can see why I was looking for a uniq id for the SP port.  As the different clariions have the same port_id.  Since it sounds like there are different structs it doesn't matter.

target2:0:3 EMC-A 50:06:01:60:C6:E0:1B:7B 655360 SP-A Port-0
target2:0:2 EMC-A 50:06:01:60:C6:E0:1B:7B 655616 SP-B Port-0
target4:0:3 EMC-A 50:06:01:60:C6:E0:1B:7B 655872 SP-B Port-4
target4:0:2 EMC-A 50:06:01:60:C6:E0:1B:7B 656128 SP-A Port-4
target4:0:0 EMC-B 50:06:01:60:C6:E0:1B:7C 655360 SP-A Port-4
target4:0:1 EMC-B 50:06:01:60:C6:E0:1B:7C 655616 SP-B Port-4
target2:0:0 EMC-B 50:06:01:60:C6:E0:1B:7C 655872 SP-B Port-0
target2:0:1 EMC-B 50:06:01:60:C6:E0:1B:7C 656128 SP-A Port-0

Thanks for the fyi on using the fc_remote_port in the future.


Note You need to log in before you can comment on or make changes to this bug.