FS
Documentation

Backup3G/COSstacker 2.1.2 Release Notes

From Documentation

< Backup3GRevision as of 01:41, 7 September 2007; view current revision
←Older revision | Newer revision→
Jump to: navigation, search

(upgrade from stacker 2.1 or 2.1.1)

Contents

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


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:


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
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
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).



January 2000
Copyright © 1990-2024 Functional Software. All rights reserved.