1. CASPUR Tape Dispatcher
Introduction
At CASPUR, we have several automated services that make use of tape drives. These drives are
shared over the fibre channel SAN. And often the same physical tape drive is called differently on
different machines, in function of the system architecture and the way it was configured on each
host. For instance, on some Linux machine a drive may be accessed as "/dev/st0", and at the same
time on another AIX machine this very drive will be called /dev/rmt3, and on yet another Solaris
host it will be named "/dev/rmt/2" etc.
On the top of this, same drive (or tape) may be claimed by several processes at the same time, and
this has to be handled somehow. Our structure is even more complex, as the same magnetic tape
may be mounted on the same host but on the different tape drives. And we have to handle several
different tape types (LTO, STK9840, DLT, AIT).
To address the management issues that arise in this distributed environment, we have introduced the
CASPUR Tape Dispatcher. This application 1) is doing a minimal bookkeeping of tape resources
(both drives and magnetic tapes); 2) is handling tape mount requests, i.e. mounts and unmounts
tapes, and 3) takes care of the resource "locking", or simply ensures that only one process at a time
may use one specific resource, such as a tape drive or some magnetic tape.
We believe that our solution may be of interest also for other sites. It may be used to handle
multiple mount requests on one or many tape mounters via the site-specific mount commands. And
it is especially useful in cases when several independent and asynchronous tasks that run on the
same or different hosts may simultaneously require the same tape resource.
Architecture
The CASPUR Tape Dispatcher is a stand-alone server process written in perl, and is fully site-
independent. Systems that need access to the tape resources communicate with the server by means
of the Tape Dispatcher API (supplied along with the server).
The site-dependent part of the system consists of 3 components:
1. System-wide configuration file, /etc/sysconfig/tapedispatcher.conf, which describes all tape
resources (drives and magnetic tapes) of the organization.
2. Current tape usage file ( /etc/sysconfig/tapedispatcher.usedtapes), which denotes the used
tapes and is dynamically managed by the server process.
3. Tape mounter command (/bin/tapemounter), which each site provides in accordance with
our specification.
The server process maintains also a log of operation in /var/log/tapedispatcher.log.
Operation
When the server process starts, it parses the configuration file and is immediately ready to serve the
requests from client hosts (only hosts mentioned in the "DRIVE" statements are served; requests
from other hosts are silently ignored).
Server controls all available drives simultaneously. For each requested drive, it keeps a "session"
with a client which grants this client exclusive rights for the device. This session remains active

2. until the client process interrupts it, or if the client process dies. During the session, client may
mount one or more different tapes on the reserved device.
There are 2 ways to establish a session, let us consider them in detail:
1. A session is established by requesting a tape with a certain VID for a service with a certain
nickname (on a specified drive, or on a first unused matching drive).
In this case the server:
o Checks whether the request has come from an authorized host.
o Checks whether the tape VID is present in the central configuration file.
o Checks whether the VID "belongs" to the nicknamed service ("usedtapes" file).
o Checks whether the caller host is mentioned in the central configuration file as
having at least one drive of the right type attached (capable to mount the requested
VID), or has access to the explicitly specified drive.
o Puts the session request into the queue.
o Assigns a first available (or explicitly specified) drive of the needed type to the client
and mounts there the requested VID, thus establishing a session.
o Within the session, serves any subsequent mount/unmount requests. For each mount,
client receives an aknowledgement, complete with the name of physical device and
VID mounted on it.
o Marks the resourse as "free", upon completion (or crash) of the client session.
2. A session is established by requesting a brand-new tape of a certain type for a service with
a certain nickname (on a specified drive, or on a first unused matching drive).
The server in this case has to "generate" the VID (in all other aspects, it operates exactly as
in case 1). That is how it is done:
o The central configuration file is searched for a first not-used tape of the matching
type.
o This tape is then marked as used by a service with the specified nickname in the
"usedtapes" file.
o Thus obtained new VID is then used to create the session.
At any moment, server may be forced to re-read its configuration file by sending a HUP signal to
the server process. All requests to server and server operations, both failed and successful, are
logged.
Download
The code is available under these conditions. The history of updates and the latest downloadable
version of CASPUR Tape Dispatcher are here:
tapedispatcher-CASPUR-0.98f.tgz (18 KB).
Update History.
The distribution contains:

3. • The ready-to-use server code (tapedispatcher), it requires only perl and will run on any
UNIX/Linux host.
• Template tapedispatcher.conf and tapedispatcher.usedtapes files that are to be placed in
/etc/sysconfig.
• A sample tapemounter front end and some library-specific scripts
• Tape Dispatcher API (set of perl functions, README file and examples of usage).
The installation is straightforward, so we do not supply any installation script:
• Make sure that you have perl and /var/log and /etc/sysconfig directories on your system.
• Carefully edit and install both tapedispatcher.conf and tapedispatcher.usedtapes
configuration files in /etc/sysconfig.
• Prepare and install your site-specific /bin/tapemounter command.
• Your system is configured! Start the server (use the rc.tdisp script that we supply) and
maybe make sure that it restarts on reboot. We suggest that you do it via inittab. For
instance, if you have unpacked the distribution directory under /etc you may add a following
line to /etc/inittab:
tdis:2345:respawn:/etc/tapedispatcher-CASPUR-0.98f/rc.tdisp
• For each of your tape-related systems involved, replace any direct tape handling with the
interface to your tape dispatcher.
• Support
• We will be happy to answer your questions, and we are interested in any error reports and
suggestions. Please feel free to contact us at tapedispatcher@caspur.it.
•
CASPUR Tape Dispatcher team:
• Ruten Gurin (architecture and implementation),
Andrei Maslennikov (architecture and documentation),
Marco Mililotti (2003-2005 Project Lead),
Andrea Petrucci (developer),
Carolina Roldan Garrido (developer)
• Copyright notice