Difference between revisions of "Device API"

From The Open Source Backup Wiki (Amanda, MySQL Backup, BackupPC)
Jump to navigationJump to search
(Start work on Device API docs.)
 
m
Line 1: Line 1:
The Device API is designed to replace the ancient [[Virtual Tape API | tapeio subsystem]] (sometimes called the vtape API or Virtual Tape API), originally introduced to support virtual tapes. The Device API clears up a large number of limitations and device assumptions that the tapeio system made, allowing native support for new devices (such as CDs and DVDs) as well as new device-related functionality (such as parallel access, partial recycling, and appending).
+
The Device API is designed to replace the ancient [[Virtual tape API | tapeio subsystem]] (sometimes called the vtape API or Virtual Tape API), originally introduced to support virtual tapes. The Device API clears up a large number of limitations and device assumptions that the tapeio system made, allowing native support for new devices (such as CDs and DVDs) as well as new device-related functionality (such as parallel access, partial recycling, and appending).
  
 
The Device API does not change (or even address) media formats. It is not itself a user-visible change, though it enables many user-visible features.
 
The Device API does not change (or even address) media formats. It is not itself a user-visible change, though it enables many user-visible features.

Revision as of 00:27, 30 August 2006

The Device API is designed to replace the ancient tapeio subsystem (sometimes called the vtape API or Virtual Tape API), originally introduced to support virtual tapes. The Device API clears up a large number of limitations and device assumptions that the tapeio system made, allowing native support for new devices (such as CDs and DVDs) as well as new device-related functionality (such as parallel access, partial recycling, and appending).

The Device API does not change (or even address) media formats. It is not itself a user-visible change, though it enables many user-visible features.

History

The original design of the tapeio system (located in tape-src/) was to abstract tape-related functionality into a separate library. Thus, different devices (tape, vtape and RAIT) were all phrased in terms of tape operations: Rewind, fast-forward, read a block, etc. Operations were assumed to have the same semantics as a UNIX tape device. Furthermore, the API revealed a file descriptor, with the assumption that other parts of Amanda could perform operations such as stat() or dup2() on it.

Limitations of tapeio

Important limitations inherent in the design of tapeio include:

  • Exposes a UNIX file descriptor
  • Operates in terms of UNIX operations
  • Does not store information in a portable (yet device-specific) way.
  • Not reentrant: Access to the device is not permitted from multiple threads or processess.
  • Assumes devices can be opened and closed at will.
  • RAIT driver performs operations in series (rather than parallel).

Operations

Tapeio included the following operations:

  • tape_access(), tape_open(), tape_stat(), tapefd_close(), tapefd_read(), tapefd_write(): Act like their UNIX equivalents
  • tapefd_rewind(), tapefd_unload(): Do what you expect.
  • tapefd_fsf(): Seeks forward a certain number of filemarks.
  • tapefd_weof(): Writes a filemark.
  • tapefd_resetofs(): Workaround for some buggy kernels.
  • tapefd_status(): Prints status to stdout (!).

In addition, all tapefd_ commands have matching tape_ commands, which work on an unopened device.

Device API Features

In addition to relieving the limitations of the tapeio system discussed above, the Device API also adds a number of new features. These include: