How to Find Lun ID in HP-UX 11.11.

[sachin9104]

Hi All,

I am unable to find LUN ID on HP-UX 11.11. I want to verify which lun id is used or unsed. 

I can simply find out hardware path and device file details. Here are short output of ioscan.

Can i find lun ID from this information or i need to use any third party tools. And one more thing i can do same task in hp-ux11.31 very easily.

ioscan -funC disk

disk 322 2/0/10/1/0/4/0.11.1.8.0.15.5 sdisk NO_HW DEVICE IBM 2145
/dev/dsk/c29t15d5 /dev/rdsk/c29t15d5
disk 324 2/0/10/1/0/4/0.11.1.8.0.15.6 sdisk NO_HW DEVICE IBM 2145
/dev/dsk/c29t15d6 /dev/rdsk/c29t15d6

[Torsten.]

disk 322 2/0/10/1/0/4/0.11.1.8.0.15.5 sdisk NO_HW DEVICE IBM 2145
/dev/dsk/c29t15d5 /dev/rdsk/c29t15d5
disk 324 2/0/10/1/0/4/0.11.1.8.0.15.6 sdisk NO_HW DEVICE IBM 2145
/dev/dsk/c29t15d6 /dev/rdsk/c29t15d6

These are probably LUN 125 and 126.

[sachin9104]

Thanks for your reply. But can you please let me know how we can calculate lun id from hardware path.

Because i have n number of lun to find out the details.

Regards,

Sachin 

[Steven Schweda]

> [...] can you please let me know how we can calculate lun id from
> hardware path.

   I know nothing, but, based on:
      c29t15d5 -> 125
      c29t15d6 -> 126
my guess would be: cCCtTTdD -> TT * 8 + D.

[Torsten.]

The keyword is volume set addressing, see my last post here

https://community.hpe.com/t5/LVM-and-VxVM/how-to-find-out-the-lun-id/td-p/5226905

The last digits of the hardware path are

.....0.15.5

now convert the last digit "5" into 3 digit binary ==> 101

and the leading "15" into binary too ==> 1111

so you get

1111 101 binary, this converts to decimal 125, this is your LUN ID.

[Steven Schweda]

> my guess would be: cCCtTTdD -> TT * 8 + D.

> The last digits of the hardware path are
> .....0.15.5
> now convert the last digit "5" into 3 digit binary ==> 101
> and the leading "15" into binary too ==> 1111
> so you get
> 1111 101 binary, this converts to decimal 125, this is your LUN ID.

   Where I come from, TT * 8 + D works in base 10, too.  Not being a
binary digital computer myself, I normally perform simple arithmetic in
base 10.  To me, this is easier than converting all the numbers to base
2, doing the arithmetic, and then converting back to decimal.

   Now, if the device path looked like, say, "c11101t1111d101", then I
_might_ do the arithmetic in base 2.  But it doesn't.

[Torsten.]

The hardware path

2/0/10/1/0/4/0.11.1.8.0.15.5

the legacy device file

/dev/dsk/c29t15d5

and the LUN are directly related.

It is getting a bit more complicated if "c" in cxtydz has to be increased to "c+1" ... because of a higher LUN number.

But it will be much simpler by using 11.31 or array specific tools like xpinfo, evainfo, 3parinfo, ...

[Steven Schweda]

> The hardware path
> 2/0/10/1/0/4/0.11.1.8.0.15.5
> the legacy device file
> /dev/dsk/c29t15d5
> and the LUN are directly related.

   I got that.  I don't care whence you get the "15" and the "5".  What
mystified me was the reason to convert these numbers to base 2, and then
the result back to base 10.  Around here, 15 * 8 + 5 = 125, no matter in
which base you do the work, so why not stick with 10?

> It is getting a bit more complicated if "c" in cxtydz has to be
> increased to "c+1" ... because of a higher LUN number.

   I assume that you mean:
      if "x" in "cxtydz" must be increased to "x+1"

[Torsten.]

you are right, it is "x", not "c".

the binary conversion is to show how it works, IIRC the complete information has 14 bits.

[Steven Schweda]

> the binary conversion is to show how it works, [...]

   Some of us can recognize 8 as being a power of two, without
converting every number in sight to base 2.  Especially when the actual
goal is a result in base 10.  (But if you enjoy the extra work, who am I
to try to dissuade you?)