Backup3G/COSstacker 2.1.2 Release Notes
From Documentation
←Older revision | Newer revision→
(upgrade from stacker 2.1 or 2.1.1)
Overview and Features
COSstacker
This patch (which is re-defined to a new release of a module) fixes issues missed during the development of Stacker 2.1 and from media misload related problems. Please refer attached table for full information. The distribution is platform specific. It will run on most UNIX platforms supported by COSbackup 3.2.1 (or newer).
New features in COSstacker
- improved error handling when media misload occurs
- support for inventory of drives within the media library (only available if the device supports barcode media labels)
- improved inventory function of media library
- configurable timeout for allocating and deallocating media via import/export slots
- ability to ignore or map alpha component of barcode label
- ability to label multiple media in one operation (only available for interface via COSduty).
Environment
Software Prerequisites
Before you can install Stacker 2.1.2, COSMOS 3.2.1 (or newer) and COSbackup 3.2.1 (or newer) must already be installed on the same host.
Stacker is a licence product. It requires a valid COSbackup (BKP) licence key.
Disk Space Required
Stacker 2.1.2 is installed under the COSbackup home directory. It requires approximately 200 Kbytes disk space.
Supported Platforms
Stacker 2.1.2 will run on most UNIX platforms supported by COSbackup. For other platforms, including Windows/NT/2000, sequential media loading only is supported.
Supported Devices
Stacker 2.1.2 will operate with all stacker devices that conform to at least the standard SCSI 2 command set for such devices.
| Operating System | Level of Support |
|---|---|
| AIX 4.1 | Full control via Functional Software supplied kernel driver |
| Digital UNIX 4 | Full control via OS passthru driver |
| HP/UX 10 and 11 | Full control via OS passthru driver |
| Linux Intel 2.2 and 2.4 kernel | Full control via OS passthru driver |
| NCR UNIX 3 | Full control via OS passthru driver |
| DC/OSx 1.1 | Sequntial access only |
| Dynix/ptx 4 | Full control via OS passthru driver |
| SGI IRIX 6 | Full control via OS passthru driver |
| Solaris 2 Intel | Sequntial access only |
| Solaris 2 Sparc | Full control via Functional Software supplied kernel driver |
| Windows/NT/2000 | Sequntial access only |
Known vendors Stacker 2.1.2 is confirmed to operate with include Storage Tek, Overland, SUN, HP, IBM, ADIC, Exabyte, Breece Hill and Quantum.
Terminology
Stacker makes reference to terminology used throughout the industry, which in some cases nay be confusing:
- Smart stacker is a device that can load media from slots in any order or in a random fashion
- Dumb stacker is a device that can only load media from slots in a sequential fashion starting with slot 1
- Autoloader is a stacker device that may operate in either Smart or Dumb mode. They usually have one drive and 6 to 8 slots
- Jukebox, silo or media library refers to stacker devices larger than an autoloader. They often have more than one drive and from 10 to hundreds of slots. Many are barcode enabled allowing for automatic inventory and electronic labelling to take place. Import/export or letterbox slots are used to insert or extract media from the devices as opening the main door would disrupt all media library operations until the door is closed.
Notes on Configuring Stacker 2.1.2
COSbackup must be installed prior to installing Stacker 2.1.2.
To install the stacker routines for use by COSbackup, install Stacker as a module using Application > Install under the Config > COSMOS Configuration > COSMOS applications menu option.
See the COSMOS user guide for details of how to install COSmanager applications.
After the installation is complete, you must setup COSbackup to support your stacker. Most of the setup should be done in the Config > COSbackup configuration > Maintain drives and stackers option. You can manage media in your stacker by using the Stacker management option (or Stacker button).
Configuring Load Operations
loadstkr and unloadstkr are two small shell scripts that call the Stacker driver, stkrctrl(1). They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For example:
Loading class stkrctrl_1 Description Random access stacker using STKRSTRL(1) Auto loading? yes Load cmd loadstkr $load_device $Device_nr $Slot $Load_posn Load next cmd [ Only used for sequential (dumb) stackers ] Unload cmd unloadstkr $load_device $Device_nr $Slot $Load_posn
 | Note |
| APPL_DB is no longer used by the DB tools so is not needed by the current COSMOS applications. However COSmanager still uses it, so it should still be set to $APPL_HOME/db. | |
If you choose to use another vendor-supplied stacker driver program, then the appropriate calls to that program must be put into the ‘Load_op’ and ‘Unload_op’ fields.
get_bcode, ie_load and ie_unload are three shell scripts that call the Stacker inventory driver, stkrinv(1), for use in the ‘Extended Stacker Operations’ of the ‘loadop’ table. For loading class stkrctrl_4 (Tape silo with barcode & multiple I/E slots) the row should be like:
COSbackup must be installed prior to installing Stacker 2.1.2.
To install the stacker routines for use by COSbackup, install Stacker as a module using Application > Install under the Config > COSMOS Configuration > COSMOS applications menu option.
See the COSMOS user guide for details of how to install COSmanager applications.
After the installation is complete, you must setup COSbackup to support your stacker. Most of the setup should be done in the Config > COSbackup configuration > Maintain drives and stackers option. You can manage media in your stacker by using the Stacker management option (or Stacker button).
Configuring Load Operations
loadstkr and unloadstkr are two small shell scripts that call the Stacker driver, stkrctrl(1). They are used in the ‘Load_op’ and ‘Unload_op’ of the ‘loadop’ table. For example:
Scan slot cmd get_bcode $Load_device $Slot Scan drive cmd get_bcode $Load_device $Load_posn Allocate cmd ie_load -t 60 $Load_device $Slot Deallocate cmd ie_unload -t 60 $Load_device $Slot
The get_bcode script is used to scan the barcode labels on the media in the slots and drives. You can modify this script to map any alpha component of the barcode label. The default mapping is to ignore any alpha characters.
The ie_load and ie_unload scripts are used to allocate and deallocate media via import/export or letterbox slots. The -t flag specifies a timeout value in seconds. If you do not insert a media for allocate or extract a media for deallocate within the time the the action will timeout. You can change the timeout value here if a different length of time is needed. The default value is 60 seconds.
Configuring Stackers
For each stacker you must create an entry in the ‘stacker’ table. For example:
Stacker ADIC-DLT7000 Description ADIC VLS DLT7000 Slots 7 Import/export slots [ leave NULL if your stacker doesn’t support these ] Operations class stkrctrl_1 Host gomez Device /dev/stkr4 Media type DLT-70
Configuring Drives in a Stacker
Define the tape drive(s) in the stacker. The ‘Loading location’ should be the name of the stacker (ADIC-DLT7000 in the above example). If the stacker has more than one drive, you need to specify the ‘Drive position’ for each, number consecutively from 1.
Before running a backup, you must allocate scratch tapes to the stacker (that is, load some into the slots). The Stacker > Move pull-down menu does this.
Warnings
WARNING: found local version of allocscr.pr You may see ERROR or WARNING messages during the installation. These are due to local COSbackup versions of certain files. The installation script creates new versions of certain COSbackup files. If local versions of these files exist (in the local COSbackup directory structure), they will be used as templates for the new files instead of the original files. As it is impossible to ascertain the modifications made to these local versions, the new files created may not be correct. The new files are created in the Stacker Module directory. “No default version of module - ignored” dialog box When upgrading from or de-installing Stacker 1.1 the message “No default version of module - ignored” is displayed in a dialog box and cannot be removed. Workaround is to run: Config > COSMOS Configuration > Maintain Tables select application table (applictn) and Change. Modify the ‘installed modules’ field to remove the stacker entry.
Hardware and OS Dependencies
Determining what device to use on AIX 4
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The AIX 4.x stacker routines require a kernel stacker driver to be installed. The kernel driver is supplied with the stacker routines, in the Driver directory. This driver must be installed seperately, using SMIT or the installp program from the command line. See the README file for instructions on installing the kernel driver. Once installed, a new SMIT menu will be setup under “Devices” to allow you to add and remove stacker devices.
The stacker device would be /dev/chgr0, created at ‘4,1’ on the appropriate SCSI adapter.
The non-rewinding tape device would be /dev/rmt1.1, created at ‘4,0’ on the same SCSI adapter.
These devices are configured using SMIT.
Determining what device to use on DU 3.2
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The Digital Unix stacker routines use the generic user agent SCSI device driver. This provides access to the SCSI/CAM subsystem and to all SCSI/CAM devices attached to the system. The SCSI commands are sent to the device via the special device called /dev/cam.
To support the stacker COSbackup needs to have a dummy device entry in the following format:
- /dev/b0t0l0
where
- b = bus
- t = target id
- l = lun
In our example, the stacker device would be /dev/b0t4l1. This device does not need to exist, it is only used to inform the stacker routines of which SCSI device to interface to.
Determining what device to use on DU 4.0
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The Digital Unix stacker routines use the CAM interface, which provides SCSI pass-through facility via the generic /dev/cam device. There is no entry in /dev created fro the stacker itself, and in order to define the stacker device to COSbackup, use a dummy device entry:
- /dev/scsiXtYlZ
where X is the SCSI bus number, Y is the target ID, and Z is the LUN of the stacker. In our example, if the stacker is on SCSI bus 0, the media changer device would be:
- /dev/scsi0t4l1
The determine the correct values to use, look in /var/adm/messages, and look for an entry like:
- vmunix: changer at scsi 0 target 4 lun 1 (LID=4)
The tape drive will be called /dev/rmtNX (where N is a number allocated sequentially from 0, and X is a letter [l, m, h or a] determining the density or compression used when writing the tape). The non-rewinding device is prefixed with ‘n’. A command like:
- file /dev/rmt0h
when run as root will give the SCSI details of the tape device.
Determining what device to use on HP/UX 10
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The HP/UX stacker routines use the generic SCSI pass-through driver, scsi_ctl(7).
The stacker device can either be an appropriate entry under the directory /dev/scsi, if one exists (for example, /dev/scsi/4 for a device at ID 4, LUN 0) or you can create an entry called, for example, /dev/stkr0 using mknod using the instructions in scsi_ctl(7).
HP/UX tape devices are allocated sequentially, their name does not correspond directly to their SCSI ID.
See HP/UX documentation for how to determine the name of the tape devices.
Determining what device to use on IRIX 6
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The IRIX stacker routines use the generic user mode SCSI driver, ds(7M).
The stacker device would be /dev/scsi/sc0d4l0.
The non-rewinding tape device would be /dev/rmt/tps0d4nr.
These devices can be configured by running /dev/MAKEDEV scsi rmt command.
The IRIX stacker driver requires that you have the ‘ds’ driver in your kernel. The driver is not always included on some hardware. If the file /var/sysgen/system/irix.sm contains a line, ‘USE: ds’, then the driver is included. If the file /var/sysgen/system/irix.sm contains a line, ‘*INCLUDE: ds’, then the driver is not included. Remove the comment character ‘*’, then relink the kernel by invoking /etc/autoconfig.
Another way to tell whether the ‘ds’ driver is included in your kernel is to check the kernel symbols:
- nm /unix | egrep “dsinit|dsopen|dsclose”
The IRIX driver may produce occasional unknown sense key warning messages.
Determining what device to use on Linux 2.2 kernel
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The linux stacker routines use the SCSI Generic (SG) Linux driver, which provides a SCSI passthrough facility using the device entries:
- /dev/sgX
where X is a letter starting from ‘a’ for the first SCSI device on the system, ‘b’ for the second and so on. The easiest way to determine which ‘sg’ device to use is to view the file:
- /proc/scsi/scsi
which will list all the SCSI devices on the system. The position of the stacker device (that will be listed as a “Medium Changer”) gives the letter to use. For example, the 3rd SCSI device will be /dev/sgc.
 | Caution! |
| If you add or remove SCSI devices from the system, the position of the stacker in the SCSI list may change, which means that you will have to change the device name. | |
Determining what device to use on Dynix/ptx 4
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
To use a stacker unter ptx, it must be supported by one of ptx’s media changer drivers (mx, ms or ml).
Stackers can be configured in two ways. A simple random access stacker (without barcode support nor import/export slots) can be configured to use ptx’s mc(1) command. To support larger tape libraries with barcode and/or import/export slots, the COSbackup driver (stkrctrl) must be used. This requires PTX 4.4.2 SPDRIVERS.
In our example, the stacker device woud be /dev/ms0, and the non-rewinding tape device /dev/td0n.
Determining what device to use on Solaris 2
Let us assume you have configured an HP1553A DAT autoloader at SCSI ID 4. The tape drive of this device is at LUN 0, and the media changer robot is at LUN 1.
The Solaris stacker routines require a kernel stacker driver to be installed. The kernel driver is supplied with the stacker routines, in the Driver directory. See the README file for instructions on onstalling the kernel driver as it will not be installed automatically.
The stacker device would be /dev/stkr4.
Solaris tape devices are allocated sequentially, their name does not correspond directly to their SCSI ID. See Solaris documentation for how to determine the name of tape devices.
Known Problems
AIX auto-configure creates two stacker devices instead of one
The AIX device driver can get confused when auto-configuring some autoloaders. This is because the driver uses the SCSI Product ID reported by the device to determine if the device is a stacker. Many autoloaders report the same Product ID for the tape drive and the stacker robot, and the driver mistakenly creates two stacker devices instead of one. This may also create a conflict with SCSI tape driver. Workaround is to use SMIT to remove the stacker device created on the tape drive ID/LUN. You may then have to ‘add’ or ‘configure’ the tape device again.
IRIX reports error sense info
The IRIX stacker driver may report: Error: sense info: key=0x02, asc=0x3a, ascq=0x00 when attempting to load from an unoccupied slot, load to an occupied drive, unload to an occupied slot, or unload from an unoccupied drive. This is not a fatal error, as the operation being performed is incorrect, and should not occur under normal operation.
We have abserved that the IRIX SCSI driver returns before the stacker robot has stopped moving when unloading tapes. It may be necessary to sleep a short while before trying a load operation immediately following an unload.
Dynix/ptx reports “Move medium command failed”
The Dynix/ptx SCSI media changer driver does not report detailed error status. Hence a message like “Move medium command failed” is all that can be reported, rather than specifying more detail (such as the source slot being empty).