About device file in 11.31

[chuanpeng.wang]

OS 11.31
Server RX8640
Storage XP512

Run xpinfo on the 11.31, there are follow information:
Device File : /dev/rdsk/c13t1d0 Model : XP512
ALPA : e4 Serial # : 00030988
Target : 02 Subsystem : 0004
LUN : 08 CT Group : ---
Port : CL1C CA Volume : SMPL
CU:LDev : 00:cb BC0 (MU#0) : SMPL
Type : OPEN-E BC1 (MU#1) : SMPL
Size : 13893 MB BC2 (MU#2) : SMPL
Code Rev : 0117 RAID Level : RAID5
Disk Mechs : R146 R156 R166 R176 RAID Group : 2-7
Port WWN : 500060e802790c02 ACP Pair : 2

Device File : /dev/rdsk/c13t1d1 Model : XP512
ALPA : cb Serial # : 00030988
Target : 12 Subsystem : 0004
LUN : 09 CT Group : ---
Port : CL2C CA Volume : SMPL
CU:LDev : 00:cc BC0 (MU#0) : SMPL
Type : OPEN-E BC1 (MU#1) : SMPL
Size : 13893 MB BC2 (MU#2) : SMPL
Code Rev : 0117 RAID Level : RAID5
Disk Mechs : R146 R156 R166 R176 RAID Group : 2-7
Port WWN : 500060e802790c12 ACP Pair : 2

Both disk's device file is c13txdx, but they connect to different XP port, CL1C and CL2C.

The ioscan as follow:
target 38 0/0/4/1/0.1.21.0.0.1 tgt CLAIMED DEVICE
disk 1004 0/0/4/1/0.1.21.0.0.1.0 sdisk CLAIMED DEVICE HP OPEN-E
/dev/dsk/c13t1d0 /dev/rdsk/c13t1d0
disk 1005 0/0/4/1/0.1.21.0.0.1.1 sdisk CLAIMED DEVICE HP OPEN-E
/dev/dsk/c13t1d1 /dev/rdsk/c13t1d1
disk 1006 0/0/4/1/0.1.21.0.0.1.2 sdisk CLAIMED DEVICE HP OPEN-E
/dev/dsk/c13t1d2 /dev/rdsk/c13t1d2

The question is why the disk device file has same C# (c13), but connect to different port.
Is it normal?
What causes this problem, the XP configuration or the 11.31 new feature?

We have another 11.11 server connect to the same XP512. On this server, the same C# match to the same XP port number.

[Duncan Edmonstone · Accepted solution]

Remember that by default 11.31 will load balance even on legacy DSFs, so older versions of xpinfo don't know this and can't "force" their disk inquiries to the correct port on the XP (cos the load balancing sends it wherever it wants!)

What version of xpinfo do you have?

xpinfo -v

You need at least rev14 for HP-UX 11.31

HTH

Duncan

[Eric SAUBIGNAC]

Bonjour,

Not yet expert with 11iv3 io stack ;-) but I guess that legacy device files has the same working way that on previous OS release.

So, what I can see in ioscan output is that devices have the same hardware path :

0/0/4/1/0.1.21.0.0.1.0 - c13t1d0
0/0/4/1/0.1.21.0.0.1.1 - c13t1d1
0/0/4/1/0.1.21.0.0.1.2 - c13t1d2

So it should be normal that lun 8 and 9 have the same controleur c13 ...
More : it seems that lun 8 and 9 are seen through the same FC card 0/0/4/1/0. Yet lun 8 is supposed to be accessed through CL1C and lun 9 through CL2C. So Os should sees them through different FC cards ....

So I suppose that you have a misconfiguration at XP level. Not an expert in XP array, but is it possible that a lun could be presented trough differents XP port ? In this case how xpinfo is supposed to interpret this situation ?

HTH

Eric

[Eric SAUBIGNAC]

Post result of following commands for c13t1d0 and c13t1d1 :

Exemple with c13t1d0 :

"ioscan -m dsf /dev/dsk/c13t0d0" --> it will give you a persistent dsf, something like "/dev/disk/disk92"

then

"ioscan -m dsf /dev/disk/disk92"

Eric

[Torsten.]

xpinfo is telling you that you access the LUNs via this certain HBA (c13...); the XP is connected to switch with domain id 1, port 21 (most likely).

you should see more device files for this lun, i think, with another c... number.

as mentioned before, try

# ioscan -m dsf

and use the new agile device file diskxx



what do you get from

# xpinfo -il

# xpinfo -p

[sujit kumar singh]

hi


the DSFs are based on the WWID of a HW LUN as assigned to a server froma storage and a storage has unique WWIDs for all the LUNs.

basics:

c13 --- this refers to the Controller (in this case the FC Interface) instance of a a LUN that the OS sees in the legacy DSF notation.

u can find this instance no and match to the legacy HW path with the command as

#ioscan -fnC ext_bus

and match the insstance no with the path of the FC controller port on the FC card or FC HBA of the server.

basiaclly the Persistent DSF is assigned for a LUN based on its WWID of the storage and is bound to the LUN HW PATH of the dev that is the path that u can see in the O/P of the command:

#ioscan -m hwpath

this DSF is therefore called


in the first column.

as the WWID bind to the LUN HW PATH, the LUN HW path of a dev does not change even if the port of that device is changed to different FC I/f or to adifferent switch , an so the DSF bound to the WWID.this DSF is therefore called persistent dsf as this is sure to remain the same if the FC port on SAN Switch or FC HBA changes because these cahnges do not chage the WWID of the LUN.


the legacy HW path to the Persistent DSF Mapping can be seen using the command

#ioscan -m dsf


regards
Sujit