Sun Storage L100 Tape Library
 

GCS>Sun Microsystems>Storage - Tape>Libraries - L-Series
 

Applies to:

Goal

Typically, administrators will manually load media into one tape drive at a time, and then run "mt -f /dev/rmt/# status" for every /dev/rmt entry until the drive information is returned. This could be a tedious operation if there were many tape drives in the backup environment.
The main problem that occurs with mis-matched tape drives and backup utility software, is devices getting "downed" because the utility calls out a device differently from the OS kernel configuration.
So for example, we end up with a situation where Legato NetWorker or Sun StorEdge[TM] Enterprise NetBackUp requests the robot to load a tape from a certain slot, and load it into tape drive /dev/rmt/0cbn. The robot actually loads the tape in drive /dev/rmt/1cbn and asks the kernel to read the label in /dev/rmt/0 so the tape can be mounted. Since no tape was ever loaded in /dev/rmt/0, the kernel tries 20 times in sequence to read the label on a tape loaded in the wrong device, and times out. This sequence error condition causes the backup utility to assume there is a bad device and puts the tape drive in a down/disabled condition.
In the following script, it assumes there are 11 tape drives connected to the system. In the initial "for" statement there is a number for every /dev/rmt entry which is present. This "for" statement may have to be modified to include more(or less) numerical values, depending on which /dev/rmt entries are created. Here is the script:

Solution

for drive in 0 1 2 3 4 5 6 7 8 9 10 ; do
mt -f /dev/rmt/$drive status
done
------------------------------------------------------------------------------
So if we copy the above information into an executable file called "mttapemap", and execute the file:
root[csh]@burtape-l40[10] ./mttapemap
Quantum DLT7000 tape drive:
sense key(0x0)= No Additional Sense   residual= 0   retries= 0
file no= 0   block no= 0
/dev/rmt/1: No such file or directory
/dev/rmt/2: No such file or directory
/dev/rmt/3: No such file or directory
/dev/rmt/4: No such file or directory
/dev/rmt/5: No such file or directory
/dev/rmt/6: No such file or directory
/dev/rmt/7: No such file or directory
/dev/rmt/8: No such file or directory
/dev/rmt/9: No such file or directory
/dev/rmt/10: No such file or directory
root[csh]@burtape-l40[11]
In this example, we know that which ever tape drive is physically loaded, correlates to the /dev/rmt/0 device.  As you can see, all of the other /dev/rmt entries report "No such file or directory".
The administrator can then proceed to manually load the other tape drives one at a time, running the mttapemap script after loading each drive to correlate the correct /dev/rmt entry.  Repeat this procedure until all physical tape drives have been mapped to their correlating /dev/rmt entry.
While performing the above process, it may be helpful to construct a matrix as shown below.  This matrix can then be used to correctly map the /dev/rmt enteries to the appropriate devices in SBU/EBS or Sun StorEdge Enterprise NetBackUp.  These backup software applications utilize their own drivers to bind to the devices, SBU/EBS utilizes the "lus" driver and Sun StorEdge Enterprise NetBackUp utilizes the "sg" driver.  When configuring devices with jbconfig (SBU/EBS) or tpconfig (Netbackup), utilize the constructed matrix to properly define the /dev/rmt devices within the backup software.
Matrix: e.g.
Drive-1 = /dev/rmt/0
Drive-2 = /dev/rmt/3
Drive-3 = /dev/rmt/6
Drive-4 = /dev/rmt/4
Drive-5 = /dev/rmt/8
~  ~  ~  ~  ~  ~  ~
Drive-11 = /dev/rmt/2

This solution has no attachment