The Volume Manager's functionality and interfaces are described here. Its components are described in more detail in the Internal Design Specification.
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.
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.
Used to allocate a scratch volume to a user. The volume type is a function of the medium and data capacity. A request will be refused if the allocation would exceed the user's quota for the repository or if no scratch volumes are available. Returns volser if successful.
List volumes that meet specs with no info, some info, or all info. Specs include volser list, owner, repository, status.
Fails if no volser meeting spec exists.
The device type and location are determined by a database query based on the volser. If a reservation is used, no request can start until all resources in the reservation can be allocated without deadlock. Last access/modified dates are updated in the database. Unless label checking is bypassed, the internal label must correspond to the version in the database; if there is no label in the database, there should be no internal label. If the mount fails in the repository due to e.g. media, device or label inconsistency, a counter of mount-failures-in-a-row is incremented in database volume record; if the mount succeeds, the counter is reset.
Request will be refused if: nonexistent volume, access permission denied, repository cannot mount the medium type, or bad label. Returns device address if successful. User accesses volume via /dev/tape/VOLSER node, which is a copy of the /dev/rmt/device node.
Used to notify the Volume Manager that the client is through with the volume or wishes to cancel an outstanding mount request by client. Request will be refused if bad volser or if the requester UID does not have the volume mounted.
The volume may be handed off to a waiting mount request using the same reservation if the mount parameters of the previous request match. The repository may also `cache' the mount, i.e. leave it silently mounted (this is only done when a dismount can happen immediately if the drive is needed for another volume).
Move a volume from current location to another.
Request will be refused if requester is not the owner or if destination quota would be exceeded.
Volume must be mounted; internal label and database version are reported/updated.
Fails if user does not have permission.
Release ownership of volume. Changes status to RECYCLE_GOOD. unless `bad' notification is given and status is RECYCLE_BAD. Volume will later be erased, recertified and made available as scratch or marked as trash and discarded. Two media failures in the recycle process are required to mark volume as trash - `bad' notification from the client counts as one.
Request will be refused if requester is not the owner or if the volume is in use.
Change read/write permissions for user, group, world.
Request will be refused if requester is not the owner or if the volume is in use.
Change owner of volume.
Request will be refused if requester is not the owner, if ownership would exceed the new owner's quota in the repository, or if the volume is in use.
Change group of volume.
Request will be refused if requester is not the owner or if the volume is in use.
Report status of current requests.
Only root or administrator account can change status.
Only root or administrator allowed.
An interactive utility is provided; must be run by root or administrator. Fails if volumes are already in database.
Must be run by root or administrator. Fails if volumes do not exist or are in use.
Must be run by root or administrator.
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:
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.
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.
Author (mail): Bill Ross
![]() |
![]() |
WebWork: Harry Waddell
NASA Official: John Lekashman |