Operating System - HP-UX
1834499 Members
2388 Online
110068 Solutions
New Discussion

Hardcode SCSI ids in 11.0 via the O/S ?

 
Barry O Flanagan
Respected Contributor

Hardcode SCSI ids in 11.0 via the O/S ?

Folks,

I have a couple of scsi tape drives (lets say a DDS and a DLT) connected to my N-class running 11.0 . Is there any way of setting the scsi ids of these drives in the O/S so that the DLT will always get a specific ID and the DDS will always get another specific one?

Usually this is do-able via dip switches etc - but I'm looking for a software method, if there is one?
12 REPLIES 12
A. Clay Stephenson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Sorry Barry,

That dog won't hunt. The SCSI ID's are a function of the device itself and not the OS.
A few SCSI devices have software configurable
SCSI ID's but that is the exception rather than the rule.

Clay
If it ain't broke, I can fix that.
James R. Ferguson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Hi Barry:

Perchance do you mean instance numbers? If so, then you can reassign them, as for instance (no pun) if you want the DDS drive to be instance zero and the DLT to be at instance one.

Regards!

...JRF...
Barry O Flanagan
Respected Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

I think I might mean instance numbers alright, if thats what determines the device filename.

tape 1 0/0/1/0.2.0 stape CLAIMED DEVICE dlt-device
/dev/rmt/1m /dev/rmt/c0t2d0BEST

tape 0 0/0/1/0.3.0 stape CLAIMED DEVICE dds-device
/dev/rmt/0m /dev/rmt/c0t3d0BESTn

This might make it clearer : in the situation above, I always want my dlt-device to use the /dev/rmt/1m device, and the dds to use 0m. So, lets say my dds drive fails and I replace it with a new one with the same SCSI ID, will the new one appear as 0m ? If I change the SCSI ID to 1 lets say, will the dds now appear as 1m (given that it'll now be the second tape device to be probed on that bus)?
Rodney Hills
Honored Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

For consistency issues, I do a hard link to my different tape drives,
eg.

ln /dev/rmt/1m /dev/tapedds
ln /dev/rmt/0m /dev/tapedlt

That way I have a consistent name in all my backup scripts.

-- Rod Hills
There be dragons...
James R. Ferguson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Hi (again) Barry:

I thought so. First, yes, the instance numbers are reflected in the device files. Thus, the tape at instance number zero has a device file /dev/rmt/0m.

If you merely replace a tape drive, because it died, then the instance number will not change. The problem of changing instance numbers is generally encountered in cold-installations where the hardware is scanned for the "first" time and instance numbers are generated in the order in which devices on buses are seen.

...JRF...
A. Clay Stephenson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Hi Barry:

Here the answer is a qualified no and sorry Rodney's approach is not bulletproof either.

The instance (the cX part of /dev/rmt/cXtYdZ...) number is determined by the order in which the hardware is 'discovered'.

If all the cards are installed in a machine, every time an OS is installed c0 remains c0, c1 remains c1, ...; however, if you started with a machine and added some cards and THEN reload the OS from scratch what was c1 MAY now be c3.

The 0m, 1m, 2m ... devices are simply shorthand
for the longer versions of the device nodes.
0m -> c0t2d0BEST, 1m ->c0t4d0BEST, 2m ->c2t3d0BEST and are for the benefit of use humans. The only thing that the machine cares about are the major and minor device numbers and that is the key.

After you determine which devive node is the one you really want by looking at the cXtYdZ stuff you simply create a new device node with the same major and minor device numbers.

e.g. lets say that you do a ls -l of /dev/rmt/c2t0d0BEST
crw-rw-rw- 2 bin 205 0x020000 Nov 12 c2t0d0BEST

Let's now make that /dev/dlttape
mknod /dev/dlttape c 205 0x020000
chmod 666 /dev/dlttape

You are now done. The bad news is that the only absolutely assured way to do this is after the fact.

Hope this helps, Clay
If it ain't broke, I can fix that.
Jason Moorhead_2
Frequent Advisor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Great tip, Clay! I am also wondering about some device files that do not have Xm (0m, 1m, etc.) numbers associated with them. I have noticed on some systems that are connected to tape libraries, either the tape drive has no /dev/rmt/Xm file (although it does have the /dev/rmt/cxtxdx files), or certain nembers are skipped (0m,2m,5m but no 1m,3m). Any idea what causes this, and would this tip help 'force' the system to recreate these files? Thanks

Jason
Barry O Flanagan
Respected Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Right - the 'grow your own' device files seems like a good plan.

But the question now is what determines the order of discovery of devices? Is it:
- scsi id?
- fastest device to respond to a probe?
- first device on the scsi chain after the controller?
- which ever way the wind is blowing?

(thanks all for your responses so far BTW)
James R. Ferguson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Hi Barry:

To my knowledge the order is the hardware path as see by 'ioscan'.

...JRF...
A. Clay Stephenson
Acclaimed Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Hi Barry:

It's definitely determined by the hardware device path and to that extent it is predictable. Again, as long as no hardware is added or deleted (or moved from one slot to another) the discovery order and thus the instance numbers remain the same.

Clay
If it ain't broke, I can fix that.
Jerry Zhang
Frequent Advisor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Tape device file is only a name associated with Major number/Minor number. For example:
212 0x001000 Jul 28 2000 0m
212 0x020000 Jul 6 2000 1m

If you remember the Major/Minor numbers for your DDS or DLT device, you can rename them to what you want. Or use mknod to create one.
Bill Hassell
Honored Contributor

Re: Hardcode SCSI ids in 11.0 via the O/S ?

Instance numbers for disks and tapes are discovered in backplane order (lowest first), then by SCSI bus ID (highest first), then (if applicable) LUN number (lowest first). When you first get a new box, the instance numbers start at the lowest numbered I/O card, typically just the multi-function card. We call this the Kitchen Sink Card because it has almost eveything except the kitchen sink on it.

However, the KSC is also the highest number in the backplane, but it is still the only card so instance numbers start at 0 for each driver. So far so good--but computers change and sysadmins add more stuff (to lower-numbered bus slots) and these new items will be scanned and added when the system reboots. Instance 0 is taken already so the new card(s) will start at instance 1. Still so far so good.

But let's cold install...if all those new cards and devices are left connected, then insf will see the lowest cards first and the KSC last. Now the KSC instance numbers are no longer 0. The system works fine but as mentioned, backup scripts or other files taken from the old environment will not match. LAN cards are similar. The lan0 device is the KSC when first installed but add a few additional LAN cards and cold install--the built-in LAN on the KSC is now lan3 or lan7...

So to control the creation order, you must disconnect devices that have been added since the original installation (that would cause a reordering of instance numbers). Then add the new cards in the order desired and reboot each time.

There is also a technique that can be used to reorder devices using ioinit but requires the standard BigBoy/BigGirl Policy statement:

"This technique will be changing the I/O config used by the kernel at bootup and mistakes (specifically to do with disk hardware) can render the system unusable and require the use of a recovery CDROM or a complete reinstall. A backup kernel will not fix I/O config file problems."

The technique is to change the file called /etc/ioconfig by using the ioinit command. Let's suppose we want to change the tape drive at 56/52.3.0 from instance 3 to instance 0, and change 56/52.1.0 from 0 to 3, thus swapping the instance numbers. Here are the steps:

# rmsf -vH 56/52.1.0
# rmsf -vH 56/52.3.0

Check the /dev/rmt diretory:

# ls /dev/rmt/

The device files for address 1 and 3 should be gone. Ignore any message from rmsf about trying to remove the driver (it can't do that anyway). Save a copy of the old ioconfig file:

# cp /etc/ioconfig /etc/ioconfig.old

Now create a file which assigns the desired instances, something like this:

56/52.1.0 tape 3
56/52.3.0 tape 0

The format is: hardware-path class instance
which can be found in the ioinit man page. This file should have all the changes you want to make. Now run ioinit to make the changes:

# ioinit -f /tmp/xx

where /tmp/xx is the file created above. If all is well, there will be no output. Run the same command again and it should report that the changes are already in place.

Now reboot. When the system comes back up, run the command:

# ioscan -knfC tape

and if no device files are shown, run the commands:

# insf -e -H 56/52.1.0
# insf -e -H 56/52.3.0

then run ioscan again. This should fix your instance numbers and device file names.


Bill Hassell, sysadmin