The problem had to do with the Non-Digital RAID controller card
reporting the same scsi name regardless of what bus/target/lun
nexus a partition was assigned. All partitions of the RAID controller
reported the same name. This caused a problem accessing other
than the first nexus.
Thanks to Dr. Thomas P. Blinn (UNIX Software Group, Compaq
Computer Corporation) and his colleagues, the problem has been
resolved.
In general, the Tru64 5.0 device handling has a great number of advantages
when done in the "normal" way. If the RAID controller I was using
could have supplied a different name for each partition, logical drive,
lun assignment, etc, or if I could have provided a name for the unit
myself, none of this would have been necessary.
The hooks are there in TU50 to deal with this kind of situation.
Unfortunately I could not find the documentation to figure this out
on my own and am indebted to Thomas Blinn for obtaining the
information necessary.
SUMMARY:
The original problem writeup:
-----------------------------------------------------------------------------
I am still having trouble with a RAID configuration from Infortrend.
I have a couple of logical drives defined and several partions on
one of the logical drives. These are assigned to SCSI ID numbers so
each one should look to the computer as a separate scsi drive
(separate nexus). At the hardware level (>>>) this is the case and
it was the case under DU 4.0F.
With TU 5.0, however, all of these end up under a single HWID.
(An example of the hwmgr command output is appended to demonstrate.)
(None of this is in a clustered environment.)
>From the System Admin guide:
Ideally, the WWID for a device is unique, enabling the
identification of every SCSI device attached to the system.
However, some legacy devices (and even some new devices
available from third-party vendors) do not provide the
information required to create a unique WWID for a specific
device. For such devices, the operating system will attempt to
generate a WWID, and in the exteme [sic] case will use the
device nexus (the SCSI bus/target/lun) to create a WWID for the
device.
If the extreme case were occurring, then a WWID and thus new HWID
would be expected for each partition and/or logical drive.
However, all partitions of logical drives and second logical drives
all go under a single HWID and I cannot figure out how to access
or name the "other paths".
I haven't found any information in the manuals/documentation on
having more than one path under a HWID.
I would like to find some way of getting each nexus under its own
HWID number or find some way of addressing the other-than-first nexus
within the single HWID.
Any pointers or solutions of any kind would be appreciated.
(Without success, I have tried scanning for one nexus, using:
hwmgr -edit scsi -did 9 -uwwid "ift 3-0-0"
to try and set a new WWID, and then scanning for the next nexus.
It still put the second one in as a new path in the same HWID.)
thanks,
-mike
-----------------------------------------------------------------------------
Michael A. Crowley Director of Networking
mcrowley_at_mtholyoke.edu 216 Dwight Hall, Mount Holyoke College
413-538-2140 fax: 413-538-2331 South Hadley, MA 01075-6415
http://www.mtholyoke.edu/~mcrowley http://www.mtholyoke.edu/lits/network
-----------------------------------------------------------------------------
---------- Forwarded message ----------
Date: Tue, 15 Feb 2000 16:52:36 -0500 (EST)
From: Michael A. Crowley <mcrowley_at_MtHolyoke.edu>
To: net_at_MtHolyoke.edu
Subject: hwmgr
hwmgr -show scsi -did 9 -full
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
88: 9 coral disk none 0 5 dsk12 [3/0/0]
WWID:04100028:"IFT 3102 002F101D"
BUS TARGET LUN PATH STATE
------------------------------
3 0 0 valid
3 1 0 valid
3 2 0 valid
3 3 0 valid
3 4 0 unknown
-----------------------------------------------------------------------------
Thomas Blinn obtained the following from one of his colleagues:
> Yes. You are correct. The devices (all of them) are telling us the have
> the SAME serial number ("002F101D"). Since the device has a serial number,
> we trust it. The fact that it's the SAME for all the units is the problem.
> Most likely, it's the RAID controllers serial number (and therefore unique
> across the controller, not to each unit on the controller). Since the
> device
> gives us this serial number, there is no reason for us to use the fallback
> WWID method of using the BTL.
>
> So, they'll need a DDR entry to modify the behavior (which means they can't
> install directly to these devices). An entry might look something like:
>
> # First option to add d/t/l to existing serial number
> SCSIDEVICE
> #
> Type = disk
> Name = "IFT" "3102"
> #
> ATTRIBUTE:
> AttributeName = "VPDinfo"
> Length = 16
> ubyte[5] = 11
>
> # Second option to eliminate serial number, and use default
> SCSIDEVICE
> #
> Type = disk
> Name = "IFT" "3102"
> #
> ATTRIBUTE:
> AttributeName = "VPDinfo"
> Length = 16
> ubyte[1] = 1
>
> # Third option to eliminate serial number and use d/b/t/l
> SCSIDEVICE
> #
> Type = disk
> Name = "IFT" "3102"
> #
> ATTRIBUTE:
> AttributeName = "VPDinfo"
> Length = 16
> ubyte[1] = 1
> ubyte[5] = 15
>
> I think the first option will work, but I've included the other 2 just in
> case the first doesn't work. The file /sys/include/io/cam/ddr_defines.h
> is where this is all documented, but there are device specific interactions
> that also play into the determination of which to use.
------- End of Forwarded Message
From: "Dr. Tom Blinn
To: Michael A Crowley <mcrowley_at_MtHolyoke.edu>
------- Forwarded Message
> The -edit function does have a specific purpose in mind. IN fact, it is
> just the OPPOSITE of this need. The problem -edit solves, is when a device
> with NO unique ID (not the case with this device) needs to HAVE a unique ID.
>
> So, this allows you to (on multiple systems that are all connected to the
> same - non-uniquely identified device) to take those non-unique names, and
> assign a single "unique" name to the device, so that all systems connected
> to it will all see it as the same device.
>
> In this case, the device DID report a unique name. If 100 people all tell
> us they live at the same address, we could call them liars, but that doesn't
> do any good in determining their "real" address. We simply have to believe
> what the hardware tells us, and all of those devices told us they were the
> SAME.
-----------------------------------------------------------------------------
All three options worked and produced slightly different WWID numbers.
Here is what came out:
My original configuration:
No ddr.dbase Options (this was the original problematic condition"
name = SCSI-WWID:04100028:"IFT 3102 002F101D"
I tested each of the options above by modifying the /etc/ddr.dbase
and recompiling with "ddr_config -c".
ACTION BASIC COMMAND
* Removed the existing HWID(s) hwmgr -delete scsi -did XX
* Modify database ddr_config -c
* scan scsi hwmgr scan scsi
* check resulting WWID hwmgr -get attr -id XXX
Option 1 -- add d/t/l to existing serial number:
name = SCSI-WWID:08100038:"IFT 3102 002F101D:d00t00000l00000"
name = SCSI-WWID:08100038:"IFT 3102 002F101D:d00t00001l00000"
name = SCSI-WWID:08100038:"IFT 3102 002F101D:d00t00002l00000"
name = SCSI-WWID:08100038:"IFT 3102 002F101D:d00t00003l00000"
Option 2 -- eliminate serial number, and use default
name = SCSI-WWID:0710002c:"IFT 3102 :d00b003t00000l00000"
name = SCSI-WWID:0710002c:"IFT 3102 :d00b003t00001l00000"
name = SCSI-WWID:0710002c:"IFT 3102 :d00b003t00002l00000"
name = SCSI-WWID:0710002c:"IFT 3102 :d00b003t00003l00000"
Option 3 -- eliminate serial number and use d/b/t/l
name = SCSI-WWID:0810002b:"IFT 3102 :d00b03t00000l00000"
name = SCSI-WWID:0810002b:"IFT 3102 :d00b03t00001l00000"
name = SCSI-WWID:0810002b:"IFT 3102 :d00b03t00002l00000"
name = SCSI-WWID:0810002b:"IFT 3102 :d00b03t00003l00000"
Since Option 1 was the main one suggested by the individual from Digital,
and since it caused the least change from the original, that is the
option I am using.
I have not yet found, however, documentation of the various ATTRIBUTE
data possibilities.
-----------------------------------------------------------------------------
Michael A. Crowley Director of Networking
mcrowley_at_mtholyoke.edu 216 Dwight Hall, Mount Holyoke College
413-538-2140 fax: 413-538-2331 South Hadley, MA 01075-6415
http://www.mtholyoke.edu/~mcrowley http://www.mtholyoke.edu/lits/network
-----------------------------------------------------------------------------
Received on Tue Feb 22 2000 - 21:27:17 NZDT