Silicon Graphics, Inc.
OpenVault
Abstract Drive Interface
Language Definition

$Id: ADI.html,v 1.27 1997/08/06 17:41:09 jbt Exp $

Overview

The Drive Control Program (DCP) is the OpenVault component that manages the configuration of drives and handles drive control tasks associated with CAPI-mount and CAPI-unmount requests for drives that are under OpenVault management.

There is at least one DCP associated with each OpenVault-managed drive. The main purpose of the DCP is to expose the drive configuration to the MLM Server and optionally to control the drive.

If there is a DCP that implements drive control in addition to exposing drive configuration, then the drive is said to have an OpenVault-accessible control interface. In this case, the MLM Server can access drive control through that DCP. OpenVault-managed drives may include both those with and without an OpenVault-accessible control interface.

Most commonly, drives are host-attached and a DCP on a host to which the drive is attached implements drive control through a host interface to the drive. A drive that is attached to multiple hosts may have multiple OpenVault-accessible control interfaces and associated DCPs -- one for each host to which that drive is attached.

Typically, if a drive is not host-attached, so that a DCP cannot control it through a host interface, the DCP does not implement drive control, so there would be no OpenVault-accessible control interface to such a drive. An example of a drive that may lack an OpenVault-accessible control interface is a video drive that is like a VCR machine, where the only way to control the drive is through an external control panel with stop, play, rewind, forward and pause control buttons.

Design goals for the DCP are to allow implementations for any:

The MLM Server interface to DCP is called the Abstract Drive Interface (ADI). ADI provides a common drive interface for the MLM Server, thus abstracting away all of the details of whether and how a DCP implements drive control. ADI is distinct from the underyling drive control interface -- it is a higher level, abstract interface. A DCP maps between ADI and the underlying drive control interface.

Functional Specification

The one object managed by a DCP is a drive.

ADI Abstraction of a Drive

capabilities and mode of access
Each drive has an associated set of capabilities, each of which describes a specific settable feature that is supported by the ADI abstraction of the drive. Capabilities determine such things as which device driver to use for control and data access, what device settings to select, and what device state to check. A particular combination of capabilities represents a particular mode of access. Each drive has a configurable set of legal modes of access, which may depend on the media types that may be accepted by the drive. The configurable set of modes includes a default mode of access. Each legal mode of access represents a logical instance of the drive with underlying control and access methods. The default mode of access for a drive depends at least in part on the type of drive (i.e., audio vs data, etc.), and possibly the type of media in the drive (eg: EXA8200 tape in an EXA8500 drive). Default modes will be defined canonically, so that they are well understood by applications.

The use of canonical capabilities and modes of access is what permits DCP to hide implementation details such as the underlying local control and access methods for the device. 

             ---------------------------------------------
             |                                           |
             |          OpenVault-accessible             |
             |            Control Interface              |
             |                                           |
             /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
             |                    |                      |
             |   Control Path     |      Data Path       |
             |                    |                      |
             ---------------------|----------   ----------
             |                               | |         |
             |                               | |         |
Mount        |              Load             | |         |
cartidge-> =====            drive  ->       =====        |
          Mount Point                  Media Access Point|
             |                                           |
             |                                           |
             ---------------------------------------------
Figure 1 - DCP conceptual view of a drive

mount point
This is the physical drive opening where a cartridge may be placed, often called the drive door. A cartridge must be present at the mount point before the cartridge can be moved to and the media it contains engaged at the media access point. When the media is disengaged from the media access point (and returned to its cartridge, as necessary), the cartridge is returned to the mount point.

media access point
This is the component that reads and writes the media contained by a cartridge. A cartridge must be moved to and the media it contains engaged at a media access point before the media can be read/write accessed. The cartridge, its media, or the media access point may physically restrict access to the media. For instance physical access to the media may be restricted to read only.

Once media is engaged at the media access point, media data may be accessed via the drive data path, if one exists.

control path
This is a control access interface between the DCP host and the drive. It is accessible by the DCP, and possibly by OpenVault Client Applications on the DCP host. Typically, underlying this interface is a physical connection, such as a local channel, bus, or shared network, between the DCP host and the drive.

data path
This is a data access interface between the DCP host and the drive media access point. It is accessible by the DCP, and by OpenVault Client Applications on the DCP host. Drives that have a control path typically also have a data path, with the control and data paths sharing the same physical connection and with access through a local device driver. For drives with a data path, DCP may require access to the drive data path in order to control the drive, for example to identify a soft partition.

A drive media access point may lack a data path. An example of a media access point that lacks a host connection and to which applications do not have access is a set of RGB lines that attach a video drive to a display device.

OpenVault-accessible control interface
Typically, an OpenVault-accessible control interface is composed of some combination of the drive control and data paths, depending on the drive and its host connectivity. Lack of DCP access to one or both of the control and data paths may cause certain ADI commands to be implemented as no-ops. A DCP implementer may control a drive by other means than control and data paths, such as by interacting with an operator or a separate software control system.

media
This is a recordable surface(s) upon which data may be read or written. A cartridge may contain one or more pieces of media. Associated with a piece of media and a drive is a media type, which determines the size of the recording surface, and a bit format, which determines the recording format.

soft partition
There are drives that support partitioning of media. A soft partition corresponds to a specific region on the media that has a physically marked beginning and ending and is only accessible from the media access point (i.e., a tape partition). The MLM Server will allow applications to mount a particular soft partition. ADI supports this by allowing the MLM Server to request that the media contained by a cartridge be positioned to a particular soft partition. For drives that do not support partioning of media, the entire recordable media surface is viewed as a single soft partition.

Currently, IRIX has limited device driver support for removable media drives that support partitioning of media. While ADI provides the required interface, the initial IRIX implementations of DCP may not support partitioned media.

local instantiation
For drives that have an OpenVault-accessible control interface, the drive must be instantiated on the DCP host before the DCP can access the drive. Typically, this involves creating a local binding between a name (i.e., device file pathname) and a logical instance of the drive (i.e., devnode), which corresponds to a particular mode of access. The name is called a drive handle. For drives that have a data path, the drive handle may be passed to and used by an OpenVault Client Application to send drive control or access media at the the media access point. When the binding is removed, the drive handle is invalidated.

Semantic Interfaces

There are two languages used for DCP-MLM Server communication:

The ADI and ADI/R use the same full-duplex, bi-directional, peer to peer low level communications as the CAPI and ALI languages.

The ADI language pair is similar to the ALI language pair.

Following is a description of the commands and command semantics of ALI and ALI/R.

ADI Command Summary

  • Initialization/instantiation
  • Media access point
  • DCP and device state synchronization
  • Drive configuration, status and history
  • Asynchronous command management

    ADI Command Semantics

    attach
    This command is supported for all OpenVault-managed drives, but is a no-op for drives that lack an OpenVault-accessible control interface, and may be a no-op if no data path underlies this interface.

    It selects the appropriate logical instance of the drive according to the mode of access that is specified by the MLM Server. It creates the logical instance of the drive, as necessary, binds an opaque drive handle to this logical instance (i.e., in UNIX environment, this equates to creating or linking to a dev node). The drive handle may either be generated by DCP or specified by the MLM Server. It must be unique on the DCP host. DCP will return an error if it detects that the drive handle is in use on the local host. Generally, the MLM Server invokes this command as part of drive selection for a CAPI-mount, after load.

    In the case that the drive is partitioned (eg: a CDROM or a high-end tape), the drive handle that will be created may be dependent on the partition. For example, most disks on UNIX platforms have the partition to be accessed encoded in the drive handle (i.e., dev node) that is created. The loaded media will be positioned to the specified partition. For drives that don't support partitioned media, a request to position to other than partition START will return an error.

    Attaching to partition START means position to the physical beginning of the recordable media surface (i.e., for tape, this is a rewind to BOT). If no partition is specified, the default is the same as attaching to position START.

    Partition names have been canonicalized, see Pre-Defined Tokens and Descriptions for more examples of partition names.

    Note that positioning the media may require the DCP to have access to a data path to the drive, and otherwise may not be supported.

    Typically, a drive has a shared control/data path. In this case, the drive handle that is passed back to the MLM Server is ultimately passed back to an OpenVault Client Application. The application uses the drive handle to establish access to the drive control/data path.

    The attach command allows the MLM Server to change the drive mode of access multiple times, without changing its name from an OpenVault Client Application point of view. However, in order for the change to affect the application, the application must re-establish its access after each attach.

    The MLM Server ensures that the specified mode of access is consistent with the drive capabilities.

    detach
    This command is supported for all OpenVault-managed drives, but is a no-op for drives that lack an OpenVault-accessible control interface.

    It removes the logical instance, as necessary, and the binding created by an attach command (i.e., in a UNIX implementation, this may equate to removing a dev node entry or a link to a dev node entry associated with this device). This invalidates a drive handle returned by a prior attach command. For drives with a shared control/data path, this disables an OpenVault Client Application from establishing access to drive control and data paths through this handle. Generally, the MLM Server invokes this command as part of drive deselection for an CAPI-unmount, before the unload command.

    The MLM Server and DCPs should try to ensure that applications do not continue to access drive control or data through a drive handle that has been invalidated by detach. Note that detach/attach may have no immediate impact on an application that was already accessing the drive control and data paths. Once the application has established its access, it may be able to proceed to access the drive control and data paths, without being affected by subsequent invocations of the attach/detach command. A case in point is with random access media and UNIX applications that perform an open-read/write-close system call sequence in which the drive handle is passed by the application as an argument only to open. In this case, the effects of the attach/detach command may only be realized upon open. The detach/attach commands may have no effect on the reads and writes that occur between open-close.

    load
    This command is supported for all OpenVault-managed drives, but is a no-op for drives that lack an OpenVault-accessible control interface.

    If there is a cartridge present at the drive mount point, this moves the cartridge to the media access point, and the engages its such that the media is accessible at the media access point. The drive is said to be loaded at this point. Minimally, load verifies that the drive is loaded. This command does not identify which media is engaged. It is invoked by the MLM Server as part of an CAPI-mount.

    Normally, the ALI mount command associated with the CAPI-mount causes the drive to be loaded (i.e., the library causes the load to happen) so the DCP load command need only verify that the drive is loaded.

    unload
    This command is supported for all OpenVault-managed drives, but is a no-op for drives that lack an OpenVault-accessible control interface.

    If the drive is loaded, this command disengages the media, returns it to its cartridge as necessary, and returns the cartridge to the drive mount point. The drive is said to be unloaded at this point. This command rewinds media before disengaging, as necessary. Minimally, it detects whether the drive is already unloaded. It is invoked by the MLM Server as part of a CAPI-unmount.

    activate
    The activate command and its variations are used to start/stop the DCP's interactions with the drive. The DCP will issue one of the ready command variations just before it has finished processing the activate command.

    This command is supported for all OpenVault-managed drives, but is a no-op for drives that lack an OpenVault-accessible control interface.

    activate enable
    This variation forces the DCP to resychronize with its drive hardware, to ensure that the DCP has current drive state. This supports drives that are attached to multiple hosts. If drive control switches from one DCP to another, the activate command ensures that the DCP that assumes control has up to date drive status.

    Note that activate enable may require the DCP to have access to a data path to the drive, in addition to a control path, and may otherwise be a no-op.

    In the case that multiple DCPs are associated with the same drive (i.e., drives attached to multiple hosts), the MLM Server ensures that only one DCP at a time is actively controlling the drive.

    activate disable
    This variation forces the DCP to complete or abort outstanding ADI commands, store any persistent state in the MLM Server that it desires to, and then stop communicating with its drive hardware to ensure that the DCP will not interfere with another DCP that will be controlling the drive. This supports drives that are attached to multiple hosts. If drive control switches from one DCP to another, the activate disable command ensures that the DCP that loses control will not interfere in the actions of another DCP.

    Note that activate disable may require the DCP to have access to a data path to the drive, in addition to a control path, and may otherwise be a no-op.

    reset
    This command tells the DCP to do whatever is required to force the drive into a (re)initialization state, including execution of any self-diagnostics that may be available. This is a best effort type of command. If it is only possible to reset a drive by resetting the whole SCSI bus, thereby interrupting other transfers on that bus, the DCP is free to treat this command as a no-op.

    exit
    This command tells the DCP to complete or abort outstanding ADI commands, store any persistent information that it desires to into the MLM Server, do any shutdown processing that might be required, then to exit.

    attribute
    This command is supported for all OpenVault-managed drives.

    Attributes are a mechanism by which information that is not contained in the normal configuration data passed to the MLM Server can be accessed. Examples include data that is unique to that drive type or data that varies over time.

    Attributes may read/write or read-only. If the attributes represent internal information or settings associated with the drive itself, the DCP would send corresponding requests to the drive, then return that information.

    show
    This command is supported for all OpenVault-managed drives. This is the attribute query mechanism.

    Note that show commands that query information directly from a drive may require that DCP have access to a data path to the drive, and otherwise may return an error.

    cancel
    This command is used to attempt to stop execution of a command sent to the DCP. The DCP is free to continue the execution of the command if the command had proceeded too far to be cancelled.

    ADI/R Command Summary

    ADI/R Command Semantics

    config
    Used to tell the MLM Server what modes of access are supported and the form factors, media types, bit formats, and performance characteristics for each.

    The config command copies configuration information, especially the offered capabilities of the drive, from the DCP up to the MLM Server for use. The MLM Server stores a non-authoritative copy of all such information for all the DCPs it controls. Each DCP must use the config command in ADI/R to update the copy of the configuration information in the MLM Server whenever it changes.

    In a full scope, all information associated with the DCP should be deleted and replaced with the information listed in the config command. In a partial scope, only the pieces of information about the DCP that are listed in the config command should be replaced. It is expected that the norm will be to use the full scope option only on startup and/or major changes to drive configuration.

    The config command is used to copy a list of each of the modes of access that the drive may be used in to the MLM Server. Each mode has a name and will have additional characteristics:

    • Supported cartridge form factors. Some drives will support different shapes of cartridges, and will offer different capabilities when using one shape when compared to another.

    • Supported media types. Some drives will support different media types. For tape, media format is equivalent to tape length.

    • Supported bit formats. Some drives will support different formats for the bits on the media, and will offer different capabilities when using one bit format when compared to another.

    • Supported capabilities. Each mode of access provides to the application a certain set of capabilities, and each capability has a name.

    • Performance information. Some drives will support different media bit formats or form factors, and will offer different performance characteristics when using one bit format or form factor when compared to another. The MLM Server may use that information when it is choosing which drive to use. For example, a drive with a read bandwidth of greater than 1MB/sec may be required for a particular application.

    The config command is additionally used to provide the core with information regarding the state of the drive (i.e. whether or not the drive is loaded). This is accomplished by using a drive clause.

    response
    Used to indicate the success or failure of an ADI command, and to pass back command results.

    message
    This is a mthod for the DCP to send a message to the operator or to a log file. It is a list of uninterpreted character strings.

    ready
    Used by the DCP to tell the MLM Server the current status of the DCP to drive connection.

    ready yes
    This tells the MLM Server that the DCP can process commands that require it to access its drive.

    ready no
    This tells the MLM Server that the DCP's drive is temporarily not available to process operations.

    ready lost
    This tells the MLM Server that the DCP has lost communications with the drive and it may be appropriate to try another control path (i.e., another DCP) in order to talk to the drive.

    ready broken
    This tells the MLM Server that the drive has developed an unrecoverable hardware error and is now unusable. This differs from ready lost in that there is no point in trying another DCP since the hardware is broken.

    attribute
    Used by the DCP to store persistent state in the OpenVault database.

    show
    Used by the DCP to query persistent state it has stored in the OpenVault database.

    cancel
    Used by the DCP to tell the MLM Server to prevent execution of a particular command, if possible.

    Syntactic Specifications

    Syntactic conventions are the same as for CAPI, including that single quotes may be used in place of double quotes.

    The ADI Language

    commands attachStmt
    detachStmt
    loadStmt
    unloadStmt
    activateStmt
    resetStmt
    exitStmt
    attributeStmt
    showStmt
    cancelStmt
    responseStmt
    attachStmt attach attachArgs ;
    attachArgs /* empty */
    task [ string ] attachArgs
    modename [ string ] attachArgs
    drivehandle [ string ] attachArgs
    partition [ string ] attachArgs
    detachStmt detach detachArgs ;
    detachArgs /* empty */
    task [ string ] detachArgs
    drivehandle [ string ] detachArgs
    loadStmt load task [ string ] ;
    unloadStmt unload task [ string ] ;
    activateStmt activate activateArgs ;
    activateArgs /* empty */
    task [ string ] activateArgs
    enable activateArgs
    disable activateArgs
    resetStmt reset task [ string ] ;
    exitStmt exit task [ string ] ;
    attributeStmt attribute attributeArgs ;
    attributeArgs /* empty */
    task [ string ] attributeArgs
    type [ string ] attributeArgs
    name [ string ] attributeArgs
    set [ string string ] attributeArgs
    unset [ string ] attributeArgs
    showStmt SHOW showArgs ;
    showArgs /* empty */
    task [ string ] showArgs
    type [ string ] showArgs
    name [ string ] showArgs
    report [ listOfStrings ] showArgs
    reportmode [ string ] showArgs
    cancelStmt cancel cancelArgs ;
    cancelArgs /* empty */
    task [ string ] cancelArgs
    whichtask [ string ] cancelArgs
    responseStmt response responseArgs ;
    responseArgs /* empty */
    whichtask [ string ] responseArgs
    accepted responseArgs
    unacceptable responseArgs
    success responseArgs
    error [ string ] responseArgs
    cancelled responseArgs
    text [ listOfStrings ] responseArgs
    listOfStrings /* empty */
    string listOfStrings
    string STRING

    The ADI/R Language

    commands configStmt
    messageStmt
    readyStmt
    attributeStmt
    showStmt
    cancelStmt
    responseStmt
    configStmt config configArgs ;
    configArgs /* empty */
    task [ string ] configArgs
    scope [ string ] configArgs
    config [ string ] configArgs
    cap [ string configCapArgs ] configArgs
    configCapArgs /* empty */
    attr [ string string ] configCapArgs
    caplist [ listOfStrings ] configCapArgs
    messageStmt message messageArgs ;
    messageArgs /* empty */
    task [ string ] messageArgs
    who [ string ] messageArgs
    severity [ string ] messageArgs
    text [ listOfStrings ] messageArgs
    readyStmt ready readyArgs ;
    readyArgs /* empty */
    task [ string ] readyArgs
    disconnected readyArgs
    not [ listOfStrings ] readyArgs
    attributeStmt attribute attributeArgs ;
    attributeArgs /* empty */
    task [ string ] attributeArgs
    type [ string ] attributeArgs
    name [ string ] attributeArgs
    set [ string string ] attributeArgs
    unset [ string ] attributeArgs
    showStmt show showArgs ;
    showArgs /* empty */
    task [ string ] showArgs
    type [ string ] showArgs
    name [ string ] showArgs
    report [ listOfStrings ] showArgs
    reportmode [ string ] showArgs
    cancelStmt cancel cancelArgs ;
    cancelArgs /* empty */
    task [ string ] cancelArgs
    whichtask [ string ] cancelArgs
    responseStmt response responseArgs ;
    responseArgs /* empty */
    whichtask [ string ] responseArgs
    accepted responseArgs
    unacceptable responseArgs
    success responseArgs
    error [ string ] responseArgs
    cancelled responseArgs
    text [ listOfStrings ] responseArgs
    listOfStrings /* empty */
    STRING listOfStrings
    string STRING

    Error Values

    Error String Meaning ADI Commands
    ADI_E_NONE no error  
    ADI_E_PART unknown/unsupported partition attach
    ADI_E_MODE unknown/unsupported mode attach
    ADI_E_HANDLE unknown/in use handle detach
    ADI_E_NOATTR unknown attribute attribute, show
    ADI_E_NOTYPE unknown type attribute, show
    ADI_E_NOCMD unknown command  
    ADI_E_NOTASK unknown task id cancel
    ADI_E_ACCESS access denied/object inaccessible attach, detach, attribute, show
    ADI_E_BADVAL bad attribute value attribute
    ADI_E_AGAIN retry recommended  
    ADI_E_READY target not ready attach, detach, load, unload, attribute, show, cancel, reset
    ADI_E_SEQUENCE command sequence error  
    ADI_E_DRIVE drive/device failure activate, attach, load, unload, attribute, show, reset

    Example ADI Requests and ADI/R Responses

    attach task['12'] modeName["base"]
    response whichtask['12'] success text["/dev/OpenVault/fred"]

    attach task['12'] modeName["base"] partition["1"]
    response whichtask['12'] success text["/dev/OpenVault/fred"]

    attach task['12'] modeName["base"] partition["80"]
    response whichtask['12'] error["ADI_E_PART"] text["specified 'partition' does not exist"]

    attach task['12'] modeName["RW"] partition["2"]
    response whichtask['12'] error["ADI_E_MODE"] text["unknown mode"]

    attach task['12'] modeName["audio"]
    response whichtask['12'] error["ADI_E_MODE"] text["mode is not supported"]

    attach task['12'] modeName["nrv"] driveHandle["/dev/rmt/tps0d3nr"]
    response whichtask['12'] error["ADI_E_HANDLE"] text["drive handle already in use"]

    attach task['12'] modeName["nrv"] driveHandle["/dev/rmt/tps0d3nr"] partition["1"]
    response whichtask['12'] error["ADI_E_HANDLE"] text["drive handle already in use"]

    attribute task['12'] type["drive"] name[""] set["writeErrors" "0"]
    response whichtask['12'] success

    attribute task['12'] type["drive"] name[""] set["BlockSize" "billion"]
    response whichtask['12'] error["ADI_E_BADVAL"] text["bad attribute value"]

    show task['12'] type["drive"] name[""] report["BitFormat"] reportMode["value"]
    response whichtask['12'] success text["dlt2000"]

    show task['12'] type["drive"] name[""] report["readErrors writeErrors"] reportMode["nameValue"]
    response whichtask['12'] success text["readErrors" "120" "writeErrors" "138"]

    show task['12'] type["DCP"] name[""] report["blah"] reporteMode["value"]
    response whichtask['12'] error["ADI_E_NOATTR"] text["unknown attribute"]

    show task['12'] type["drive"] name[""] report["totalWriteErrors"] reportMode["value"]
    response whichtask['12'] error["ADI_E_NOATTR"] text["attribute not supported"]

    load task['12']
    response whichtask['12'] error["ADI_E_NOCMD"] text["command is not supported"]

    unload task['12']
    response whichtask['12'] success

    detach task['12'] driveHandle["/dev/rmt/tps0d3nr"]
    response whichtask['12'] success

    Implementation

    DCP Structure

    At least one DCP is associated with each drive that is under OpenVault management. Normally, a drive is controlled through a host to which it is physically attached. The associated DCP resides on that host and interfaces to the drive through an underlying local device driver. For a multi-hosted drive, multiple DCPs are associated with the drive, one for each host to which the drive is attached. The DCP associated with a drive that has no OpenVault-accessible access interface may reside on any host so long as it can communicate with the MLM Server.

    IPC, Authentication and Access Control

    The underlying interprocess communication and authentication mechanisms for ADI are the same as for CAPI.

    A DCP may only support or be used by one MLM Server, so a DCP must have a means to authenticate the MLM Server.

    DCP may have to run with privileges in order to implement the binding of a drive handle to a logical instance of a drive (i.e., under UNIX, a DCP must run as root in order to perform setuid & setgid ops so it can create and remove dev nodes).

    Drive and DCP Control Centralized in MLM Server

    Administration and coordination of drives and DCPs is centralized within the MLM Server. The MLM Server maintains in a database information about drives that are under its management. Some of this information is persistent, such as the drives that the MLM Server manages and the DCP that is currently controlling the drive. Other information is collected by the MLM Server from DCPs, including DCP communication address and configuration. The MLM Server consults its database to assist it with drive selection and routing requests to the correct DCP.

    The MLM Server ensures that only one DCP at a time is actively controlling a drive that is attached to multiple hosts. If the MLM Server switches the controlling DCP, it sends an activate disable command to the old controlling DCP to force it to stop communicating with the drive hardware, then it sends an activate enable command to the new controlling DCP to force it to resynchronize with the drive hardware.

    Capabilties and Legal Modes of Access

    A legal mode of access is expressed a combination of a set of capabilities, and a DCP may have several legal modes of access for its drive. At boot time, the DCP reports its legal modes of access to the MLM Server as part of its configuration.

    OpenVault uses this information to assist with drive selection. It has a mechanism by which it can compare the desired or requested mode of access with the legal modes of access for a DCP.

    There will be a canonicalized list of capability names that applications can request and DCPs may advertise, thereby allowing the MLM Server to match application requrements against DCP abilities.

    State and Fault Tolerance

    A key OpenVault goal that impacts the strategy of its slave control programs for managing state is that a control program should maintain minimal persistent state in order to accelerate crash recovery for control programs. A DCP-specific goal for fault tolerance is that DCP should avoid interfering with application access to the drive whenever possible, including across DCP reboots. The DCP strategy for managing internal state attempts to balance these two somewhat conflicting goals. In order to support continuous application access to the drive, a DCP must maintain some persistent state.

    Consider that once it has a drive handle for a host-attached drive, an OpenVault Client Application may establish access to the drive independent of the state of the DCP. Even if the DCP crashes, so long as the application/DCP-host remains up and the drive control and data paths remain available, the application may continue to access the drive. The DCP should not interrupt this access unnecessarily.

    There is a back-channel protocol from the DCP to the MLM Server, called ADI/R, which includes the means to create/access persistent attributes stored in the OpanVault database. When a DCP boots, it queries the OpanVault database to recover any state it deems neccessary from those attributes.

    Configuration

    The following drive configuration attributes will be maintained by DCP for its drive. These attributes will be maintained persistently, such as in a configuration file on the machine where DCP resides.

    Minimum Set

    MLM Server communications address
    This is the name of the host (or IP addresss) on which the MLM Server resides. The MLM Server resides at a Well Known Address on that host. This information is in the DCP configuration in order to enable the DCP upon boot to initiate contact with the MLM Server.
    drive name
    This is the name by which the MLM Server knows the drive. Drive names are unique within the context of a single MLM Server. The MLM Server uses this information to detect multi-hosted drives. For multi-hosted drives, each controlling DCP has the same drive name.
    physical type
    This describes physical properties like cartridge form factor, i.e., DLT, 4mm, 8mm, etc., and media interchangeability, i.e., DLT2000, DLT4000, 8mm-8500, etc. These properties will be canonicalized.
    access control settings
    This is configuration to enable or disable certain OpenVault Client Application access to the drive control and data paths on this host.
    access method mapping
    The configuration file may define the mapping between each legal mode of access and the drive handle and/or the local access method used to accomplish that mode of access. Please see the System Startup and Restart document for an example of this mapping for the case that IRIX tpsc and dev nodes represent the underlying control and access methods.

    From Device

    current status/sense bytes
    current mode i.e., audio vs data
    statistics
    error history
    manufacturer
    firmware revision

    Possible Extras

    DCP-maintained statistics
    vendor specifications i.e., MTTF, MTTR, r/w bit-err-rate, cleaning req's,
    avg & max r/w throughput, avg & max load and positioning time, etc.
    access pattern i.e., random, sequential
    media class i.e., RW mag tape, RW optical disk, WORM optical disk, WORM optical tape, etc.
    device protocol i.e., SCSI, SCSI2, IPI3, etc.

    Decisions, Assumptions and Limitations

    A single DCP may service only one MLM Server.

    While DCP may be tested in a standalone mode, it cannot be operated in a standalone mode. It must be front-ended by the MLM Server.

    All drives under OpenVault management have an associated DCP, minimally to manage drive configuration. However, drive-control is exercised only for drives that have an OpenVault-accessible control interface. For these drives, a current requirement is that the OpenVault Client Application reside on the same host as the controlling DCP. The drive handle issued by a controlling DCP is assumed to be meaningful only in the context of the host on which that DCP resides. The drive control and data paths are directly accessible by an application on the same host as the controlling DCP. Once the application has a drive handle, it may access drive control and data paths directly, independently of the DCP.

    A decision regarding drives that have an OpenVault-accessible access interface is to require the OpenVault Client Application and controlling DCP to reside on the same host. While multiple quasi-standards for remote access to drives exist, currently, there is no standard mechanism that works across all operating system and network environments. OpenVault does not attempt to provide such a mechanism. This decision limits the types of failures from which a DCP can recover on its own in order to achieve high availability. Specifically, it makes no sense to failover a DCP alone. Failover would only be effective at the host level, so that the application and DCP are failed over together to another host to which the drive is connected. Given that DCP hosts may be from different vendors, and running different OSs, it is not clear how host failover will be handled, or whether a generic mechanism is required. IRIS FailSafe may be sufficient to achieve high availability for DCP on paired IRIX systems.

    The MLM Server must ensure that

    • only one application at a time attempts to use a drive
    • only one DCP at a time is controlling a drive
    • the selected DCP's configuration is consistent with drive characteristics specified as part of CAPI-mount
    • the selected DCP allows the drive to be accessed by the OpenVault Client Application

    Not all ADI abstractions and commands are supported for all drives. For example, drives that have no OpenVault-accessible control interface have no underlying control and access methods on the DCP host. For these drives, only the attribute and show commands are supported.

    Not all DCP attributes and modes of access apply to all drives.

    No drive name is passed in commands or responses, since this is implicit in the DCP that was selected by the MLM Server.

    The modeName argument to the attach command is intended to be extensible in the sense that new capabilities may be added as needed to support new drives.

    Drive mode is only included in the attach command. If an MLM Server wants to leave a drive mounted, allow the application to access the drive through the same drive handle, but with different settings or access permissions, it must do another attach. An application must re-establish access to a drive (i.e., under UNIX, close and then open the drive) after attach in order for new mode or access permissions to have effect.

    The attach command intentionally allows media positioning only at the granularity of partition, since the DCP view of media is that it is divided into one or more physical partitions. Positioning to finer granularity (i.e., tape file or record marks) is handled by the OpenVault Client Application.

    For some drive types that support partitioned media, the unload command need not, in fact should not, cause a rewind. This is to reduce average seek time.

    It is assumed that DCP is the only reliable authority with respect to drive configuration.

    It is assumed that there will be an authority (either under OpenVault or the IRIX operating system) for the canonical lists of the devices and media that are supported under the IRIX operating system. Names used within OpenVault to identify device and media types are consistent with the information maintained by this authority.

    It is assumed that the MLM Server performs access checks to enforce access control specified in DCP configuration.

    The following operations were intentionally left out of the DCP specification. It is expected that these will be implemented by OpenVault Client Applications, as necessary.

    retension media
    sniff application label
    create media partition
    get media position
    write media identifier
    clean drive
    erase media

    Open Issues

    Need to explore state management, autoconfiguration, crash recovery and high availability in more detail. A point that is unique to DCPs and drives that have an OpenVault-accessible control interface is that OpenVault Client Applications have direct access to the device. A high-availability implementation needs to take into consideration that the application resides on the same host as this DCP.

    The attach (with a position argument) command has performance implications. For high capacity media, such as D2, that need not be rewound between mount/unmount, and for which the average search or position time is relatively long, it would be undesirable to position back to the beginning of the media for each mount.

    Need to define canonically the default modes of access to different types of drives.

    Need to expand upon idea and implementation of authority for devices supported under IRIX.