Changer API

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)
Revision as of 22:23, 16 December 2008 by Dustin (talk | contribs) (new link for config)
Jump to navigationJump to search

This is a developer-level description of Changer API v. 2.0, which was introduced in Amanda-2.6.1. For the old (pre-2.6.1) changer API, see Changer API (1.0).

Links

  • Detailed documentation of the Changer API is available directly in the source code, in the form of perldoc. See Amanda::Changer.
  • The details of changer configuration

Motivation for the Change

The previous Changer API (1.0) had a few design deficiencies which made it incompatible with the needs of future versions of Amanda.

  • All changer invocations are synchronous - Amanda stops to wait for the changer operation to complete.
  • There is no mechanism to mark a device as "in use." Amanda has historically handled this by only allowing one process with access to the drive to run at any time, but modern users demand more concurrency than this.
  • There is no mechanism to operate multiple, independent changers simultaneously - nor even to configure them. Tape-changer configuration is done with global Amanda parameters, and most scripts fetch their configuration using amgetconf(8).
  • The exiting interface requires callers to handle four semantically distinct types of changers: no changer at all (tpchanger=), gravity changers, unsearchable changers, and searchable changers.
  • The exiting interface does not support advanced operations such as importing or exporting tapes or moving them from slot to slot.

Operational Overview

The changer API is a collection of perl modules with the common prefix Amanda::Changer. Changers are represented as objects, with (among others) a sophisticated load() method which loads a volume and returns a reservation object. The caller has exclusive use of the underlying device until the reservation is explicitly released. Other parts of the same application, or other processes entirely, can reserve other volumes, assuming that the necessary resources are available (drives, SCSI IDs, whatever).

All operations are asynchronous, meaning that other activities such as file transfers can continue while the changer is performing an operation. As a result, the caller must be running an Amanda::MainLoop, and the resulting Perl contains a lot of anonymous subs serving as callbacks.

Slots

To support older functionality in Amanda, this version of the API has inherited a vague notion of "slot" from the 1.0 API. Note that this concept is ill-defined for *all* changers!

  • for chg-zd-mtx, when e.g., slot "6" is loaded, the tape is actually physically located in the drive (perhaps slot 0), and the changer hardware/driver merely "remembers" that the tape came from slot 6. The user could certainly move another tape to slot 6 in the interim, which would leave chg-zd-mtx at a loss when it tried to unload the tape from the drive.
  • for chg-multi, a slot is the same as a drive, and media is never moved in or out of drives
  • for chg-disk, a slot is a substring of a subdirectory name, but only the "current" slot is accessible (via symlink)
  • for chg-rait, a slot is defined by the slots of the sub-changers

Within the 2.0 API, this concept is still present, mostly to support the taperscan algorithm and to allow users to perform administrative tasks via amtape. Slots are arbitrary user-displayable strings meaning only "a place to look for a volume". A changer must maintain a "current" slot, and must pass along a "next" slot with each reservation. No further meaning is expected of slots, and new uses of the API should avoid reference to the concept as much as possible.