NAStore External Reference Specification

The NAStore Volume Manager
External Reference Specification

Bill Ross
Network Archive Systems

The Volume Manager is the NAStore component for management of physical (removable) volumes. It is a stand-alone package that can be used independently of NAStore.

The Volume Manager's functionality and interfaces are described here. Its components are described in more detail in the Internal Design Specification.


Introduction

NAStore migrates files' data from disk to lower cost, slower access media, i.e. removable volumes. The Volume Manager keeps track of such volumes both for NAStore and other clients, providing a consistent interface for mounting and moving various media as well universal access control. The interface emulates Unix treatment of files where possible, e.g. there is a vchmod(1) command for volumes corresponding to the Unix chmod(1) for files. The shell command and programmatic interfaces are documented in about 15 Unix man pages, introduced by volman(8).

Multi-host configuration and deadlock-free resource management are provided.

The types of storage currently supported are 3480/3490 and D3 tape cartridges, loaded both automatically by robot and manually by operator.

Simplified View of Components

	[block diagram - gif]

Responsibilities

The Volume Manager has two major responsibilities: volume cataloging and volume access. Cataloging is performed by a volume library database, while access is provided by communicating with agents such as an operator or a robot controller.

Volume Cataloging

The Volume Manager maintains a database which records volume attributes such as medium, location, ownership, access permission and access time. Each volume is given a unique volser (volume serial number) which corresponds to an external label. Internal ANSI ``VOL1'' labels and internal label checking are also supported.

Volume record description

Volume and Resource Access

The Volume Manager services requests from users and programs wishing to access specified volumes, checking permissions and allocating the devices on which volumes are mounted.

Volume Allocation and Creation When requesting scratch volumes, the client specifies a repository (location) and volume type, and is returned a volser. If a user wishes to enter a volume into the system, the operator applies a new external label unless an existing label happens to be unique in the database. The internal (i.e. magnetic) label is also checked to ensure that it is unique to the user; duplicate magnetic labels for a user are refused. The system administrator may enter dummy volumes into the database to allow non-system volumes to be mounted according to local protocol, typically by arrangement between a user and an operator or by a user on a drive in an unsecured location.
Utility references: volalloc(1), volentdb(1M.

Volume Reference When requesting operations on volumes, the user only specifies the volser: other information is determined from the volume's record in the database.

Volume Access Access permissions are handled in a manner analogous to Unix files (System V version). Mounts may only occur in the volume's current location (assuming there are appropriate drives there). If a mount is desired in another location, the volume must first be moved to that location. Clients under the same UID can appropriate and cancel each other's outstanding requests.
Utility references: vls(1), vchmod(1), vchown(1), vchgrp(1), vol(1), volmv(1).

Drive Allocation Drives are allocated in the repository containing a requested volume. A mount request is queued if no drive is available, and operators are notified if varying on a drive would free a pending request. The user cannot request a mount on a specific drive. The Volume Manager attempts to select drives such that all system resources (drives, storage controllers, data paths etc.) are maximally utilized.

Users can reserve drives and volumes in advance in order to avoid deadlock on parallel requests. `Hard' drive reservations also can be used to guarantee no-wait mounts.

Quotas Quotas are used for expensive repositories (e.g. the ACS) to limit the number of volumes each user may have there. Quotas are checked and updated when volumes are moved or when scratch volumes are allocated or recycled. The Volume Manager account quota is set to the capacity of the repository. Free space is also monitored.

If a request is refused due to quota limitations, a user may use the vls(1) utility to obtain a list of his or her volumes stored at the location in question and the volmv(1) utility to move one or more of the volumes to another location.

Volume Manager Requests (and request parameters):

A Typical Mount Scenario (Volume Manager's point of view):

In NAStore the bulk of user requests come from rash(8).

Interface

A C library provides access to application programs. A command-line interface is also available.

The C library is described in volop(3) and libvol(3). It enables any user process to establish communication with and become a client of the Volume Manager. Client requests can specify the type of status notification desired, if any.

The command-line interface is described in volman(8). User and operator utilities are listed below:

User Utilities

Operator Utilities

Console

Console functions are served by broadcasting messages to designated login names which are able to run appropriate utilities to talk back.

Volume Manager Operator Console The Volume Manager modules broadcast urgent messages to /dev/console and to all logins under the volman account, which is determined by the administrator. The account also has run permission on utilities for interrogating status and issuing commands, including volvary(1M) and vshutdown(1M). If no terminal is logged in or if a broadcast fails (e.g. if a tube screen is full) no message will be written and processing will continue.

Vault Repository Controller The Vault Repository Controller or vaultrc(1M) broadcasts messages such as mounts, dismounts and moves (to/from ACS) to a designated login name (which happens to be volman). If no login exists to receive a broadcast, operators will not receive requests.

ACS Repository Controller(s) Each ACS Repository Controller or acsrc(1M) manages a StorageTek tape robot farm of one or more silos. It can broadcast status to a designated account (normally acs, but disabled in the current vold(1M) configuration) and broadcasts error messages and requests for operator action to the volman account.

Servers

Vold(1M) is the central server that manages the database and allocates resources.

Volcd(1M) or client daemon runs on each host served by the system and manages user connections.

Volnd(1M) or node daemon runs on each host served by the system and manages device data paths, i.e. checks internal labels and creates the /dev/vol/xxxxxx client access nodes.

Vaultrc(1M) manages activity in the operator-controlled vault.

Acsrc(1M) manages a StorageTek ACS tape robot farm.

See the Volume Manager Internal Design Specification for detailed coverage of the components.

Author (mail): Bill Ross


 NAS HOME PAGE  Storage Systems home page WebWork: Harry Waddell
NASA Official: John Lekashman