Mapping device names to LUNs in Solaris 10

After a bunch of digging, I was finally able to figure out how to getthe LUN from the /dev/dsk/cNtGUIDdNsN device name. It involves using the luxadm (1m) command, and looking at the "Device Address" field. The part after the ',' is the LUN in hex. In the following example the LUN (shown in bold) is 16:

datum:~# luxadm display /dev/rdsk/c4t600601608ED80800C109FE8C4652DB11d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c4t600601608ED80800C109FE8C4652DB11d0s2
Vendor: DGC
Product ID: RAID 3
Revision: 0219
Serial Num: APM000317000
Unformatted capacity: 20480.000 MBytes
Read Cache: Enabled
Minimum prefetch: 0x0
Maximum prefetch: 0x0
Device Type: Disk device
Path(s):

/dev/rdsk/c4t600601608ED80800C109FE8C4652DB11d0s2
/devices/scsi_vhci/ssd@g600601608ed80800c109fe8c4652db11:c,raw
Controller /devices/pci@7c0/pci@0/pci@8/SUNW,emlxs@0/fp@0,0
Device Address 5006016220600008,10
Host controller port WWN 10000000c957a610
Class primary
State ONLINE
Controller /devices/pci@7c0/pci@0/pci@8/SUNW,emlxs@0/fp@0,0
Device Address 5006016320600008,10
Host controller port WWN 10000000c957a610
Class primary
State ONLINE
Controller /devices/pci@7c0/pci@0/pci@8/SUNW,emlxs@0/fp@0,0
Device Address 5006016a20600008,10
Host controller port WWN 10000000c957a610
Class secondary
State STANDBY
Controller /devices/pci@7c0/pci@0/pci@8/SUNW,emlxs@0/fp@0,0
Device Address 5006016b20600008,10
Host controller port WWN 10000000c957a610
Class secondary
State STANDBY
Controller /devices/pci@7c0/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
Device Address 5006016120600008,10
Host controller port WWN 10000000c957a3ed
Class primary
State ONLINE
Controller /devices/pci@7c0/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
Device Address 5006016020600008,10
Host controller port WWN 10000000c957a3ed
Class primary
State ONLINE
Controller /devices/pci@7c0/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
Device Address 5006016820600008,10
Host controller port WWN 10000000c957a3ed
Class secondary
State STANDBY
Controller /devices/pci@7c0/pci@0/pci@9/SUNW,emlxs@0/fp@0,0
Device Address 5006016920600008,10
Host controller port WWN 10000000c957a3ed
Class secondary
State STANDBY

C++ is evil

Somewhere between TSM version 5.2.4 and 5.4.0 the XBSA library changed to a C++ library, which means it needed the C++ run-time libraries to run. The problem is that when using dlopen(3c) to load this library from a standard C application the C++ run-time libraries don't get loaded properly. We ran into this when our AFS backup system stopped working after we upgraded our TSM clients to 5.4.0 (bad IBM!). It turns out that ld.so.1(1) has some cool debugging flags which made finding the problem pretty easy. You can setenv LD_DEBUG to a list of parameters, run your program, and *poof*, you have all the information you need on how the dynamic libraries are loaded.

As it turns out, it was a 2 line fix to the AFS butc source code to pre-load the C++ libraries, and all is happy. The patch can be found here.