c4t0d1 - Explaination

[dasn]

As per admin guide this no represents,
c# - Instance No of the interface card
t# - SCSI target add
d# - Device no

In my system the instance no of my fc cards are...
# ioscan -fC fc
Class I H/W Path Driver S/W State H/W Type Description
=================================================================
fc 0 0/2/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
fc 1 0/4/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
#

From the above output they are 0 and 1.
Interstingly, my storage connected to the server has the following name...

# ioscan -fnC disk
Class I H/W Path Driver S/W State H/W Type Description
=======================================================================
disk 1 0/0/1/1.15.0 sdisk CLAIMED DEVICE SEAGATE ST318404LC
/dev/dsk/c1t15d0 /dev/rdsk/c1t15d0
disk 5 0/2/0/0.2.0.255.0.0.0 sdisk CLAIMED DEVICE HITACHI DF500
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 12 0/2/0/0.2.0.255.0.0.1 sdisk CLAIMED DEVICE HITACHI DF500
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1
disk 17 0/4/0/0.1.0.255.0.0.0 sdisk CLAIMED DEVICE HITACHI DF500
/dev/dsk/c4t0d0 /dev/rdsk/c4t0d0
disk 18 0/4/0/0.1.0.255.0.0.1 sdisk CLAIMED DEVICE HITACHI DF500
/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1
#

Please look at the nos...why is this difference ?

Thanks,
Niranjan

[spex]

Hello,

I believe you are referring to the duplicate instance numbers.

Please refer to the following section from the ioscan(1M) manpage:


The instance number associated with the device or
card. It is a unique number assigned to a card or
device within a class. If no driver is available
for the hardware component or an error occurs
binding the driver, the kernel will not assign an
instance number and a (-1), is listed.

So the number must be unique within a class, but not necessarily across classes (fd vs. disk), which is what you are seeing. Regardless, the hardware path and device files are far more useful in identifying physical hierarchy.

PCS

[dasn]

I have also found that, when H/W path to the FC card is passed as argument to the ioscan, it displays the following info.

# ioscan -fH 0/2/0/0
Class I H/W Path Driver S/W State H/W Type Description
======================================================================
fc 0 0/2/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
fcp 0 0/2/0/0.2 fcp CLAIMED INTERFACE FCP Domain
ext_bus 6 0/2/0/0.2.0.255.0 fcpdev CLAIMED INTERFACE FCP Device Interface
target 0 0/2/0/0.2.0.255.0.0 tgt CLAIMED DEVICE
disk 5 0/2/0/0.2.0.255.0.0.0 sdisk CLAIMED DEVICE HITACHI DF500
disk 12 0/2/0/0.2.0.255.0.0.1 sdisk CLAIMED DEVICE HITACHI DF500
#
#
# ioscan -fH 0/4/0/0
Class I H/W Path Driver S/W State H/W Type Description
======================================================================
fc 1 0/4/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS Fibre Channel Mass Storage Adapter
fcp 1 0/4/0/0.1 fcp CLAIMED INTERFACE FCP Domain
ext_bus 4 0/4/0/0.1.0.255.0 fcpdev CLAIMED INTERFACE FCP Device Interface
target 5 0/4/0/0.1.0.255.0.0 tgt CLAIMED DEVICE
disk 17 0/4/0/0.1.0.255.0.0.0 sdisk CLAIMED DEVICE HITACHI DF500
disk 18 0/4/0/0.1.0.255.0.0.1 sdisk CLAIMED DEVICE HITACHI DF500
#

In the above output each FC card has a component called "ext_bus" which has the exact instance no, which my storage disks are displaying. Now the question is, why is this too many levels of hierarchy and what do they singnify?

Hierarchy i mean is...
fc->fcp->ext_bus where the disks are tied.

Thanks for the reply.
NKD

[Matti_Kurkela]

The controller number in the c#t#d# numbering is counting both SCSI and FC devices: a disk is a disk, whatever the access method.

The extra hierarchy level is there because FC can support a lot more disks (LUNs) per FC interface than a SCSI bus.

On HP-UX 11.23 and below, the designers at HP had chosen to make FC look as much like SCSI as possible. To cover the huge LUN space of the FC, the FC driver creates ext_bus entries as needed.

Apparently on HP-UX 11.31 there has been a major storage re-implementation: the old-style device names can still be used, but internally they will use the new mechanisms, which are more tightly coupled to "native" FC addressing. You can get the WWID numbers of the disks from ioscan if you want, for example.

(I just received a dose of HP-UX 11.31 marketing... :-)

MK

[Senthil Kumar .A_1]

Hi Dasn,

You were right when you told, the instance number of ext_bus gets put in c# part of c#t#d#. Always the reference point of the disk is from ext_bus -> target -> lun number.

The extra hierarchy before ext_bus, just indicates how many bus nexus the cpu needs to cross before reaching the target disk. If you would have worked with old hp servers like G class, F claas, the hardware hieracy was very simple. Very less bus nexus, meaning short path hierarchy numbers. But if you notice in recent pa-risc and itanium, you will find lot more cossovers. Having said this, thaere is one more distinct difference between "direct scsi" attach and disks on SAN. In direct scsi attach, after the bus nexus the cpu almost directly lands up on controller it self. whereas, in SAN environment, there are some extra work to be done, because, the scsi packets gets tunneled through fc protocol.
In your case, SAN environemnt, the disks that are displayed are not accessed through internal scsi card, instead it is accessed through your FC card. Hence the fist part,

fc (represents your FC card it self)

second part, is to embed the "SAN switch domain" number in the path. Reason being, the system should know, to which switch it needs or send a data packcet in a SAN fabric. So thats your

"fcp" part (FCP represents the domain number of the end switch to which target array is connected, it may be just 8 in HP environment if Private loop ALPA topology is used).

By now the system has access to the SAN storage itself, so creates a virtual "ext_bus" from here on. And starts employing vitual set addressing or logical numbering as per the scsi addressing rules.

Summary :

n/n/n/n/x.x.x.y.y.y

n/n/n/n --> bus nexus jumps
x.x.x --> for traversing the SAN fabric
y.y.y --> to foolwo the norms of scsi and access the drive itself.

SK

[dasn]

The above replies were beneficial and got my doubt clear to a extent.

Thanks,
NKD