Purpose
The Reference Model for Open Storage Systems Interconnection (OSSI Model) provides a framework for the coordination of standards development for storage systems interconnection and a common perspective for existing standards. Through development of this structured framework, the OSSI Model exposes areas where standards are necessary or need improvement.
The technology and application independence of the OSSI Model accommodates descriptions of advanced technologies and expansion in user demands. This flexibility also supports the phased transition from existing implementations to OSSI standards.
It is not the intent of the OSSI Model to serve as an implementation specification, to be a basis for appraising the conformance of actual implementations, or to define precisely the standards for services and protocols of the interconnection architecture. Rather, the OSSI Model provides a conceptual and functional framework that allows teams of experts to work productively and independently on the development of standards for OSSI.
Modeling the Open Storage System
The scope of the OSSI Model is open storage systems and the environment that an open storage system must function within.
An open storage system is a storage system that complies with the requirements of OSSI standards. A storage system is the set of mechanisms that are necessary to store and retrieve a stream of bits. The storage system has no notion of the information represented by this data.
An open storage system is an abstraction used to describe storage system implementations. A storage system implementation is a set of devices, associated software, operators, physical processes, etc., that provides services for the storage and retrieval of data. A storage system implementation is open if it complies with the requirements of OSSI (IEEE P1244) standards in its interaction with clients.
The varying requirements of specific systems mandate that storage system implementations operate in diverse environments. In an open system, the environment provides common services used by open storage systems. These common services rely on mechanisms governed by commercial availability, management policy and implementation-dependent architecture requirements. Site-specific constraints may also force distribution and scalability requirements onto the open storage system implementation. The OSSI Model presents an abstract view of the open storage system independent of these environmental, distribution and scalability contexts.
Model Summary
OSSI Model Overview
The OSSI Model describes services that affect or report the state of storage objects and storage object relationships. Modules provide disjoint sets of services, and as such, define the client's view of the Model. Clients request services from modules through programmatic interfaces supported by services in the environment (e.g., communications and security).
A module can act as a client and request services of another module. A module executes independently from its client. A module responds to requests for services and can notify clients of events associated with an object. Clients and modules are implemented by a collection of hardware or software.
The client's view of the service interface is through an abstract communications service that accepts requests, and that may return a reply. Possible implementations include a subroutine call mechanism with event notification, message passing, and remote procedure calls.
All services in the open storage system are coupled to one or more objects. These objects abstract the fundamental elements within storage system implementations.
Functional Overview
The Reference Model for Open Storage Systems Interconnection is a framework for storage systems design. It decomposes a complete storage system into storage objects, storage modules, and an overall computing environment (Figure 1). Section 3 provides a detailed presentation of the storage objects. Section 4 presents a description of the storage modules. Section 5 describes the services required of the storage system environment.
In each of the following paragraphs, a storage object is introduced in addition to the storage module which presents the OSSI Model defined interface for that object:
Devices are storage objects that copy data to and from storage media. The Mover is a storage module that presents the Model-defined interface to devices to manage the transfer of data between source and sink devices.
Cartridges are storage objects that contain storage media. The Physical Volume Repository (PVR) is a storage module that stows cartridges and mounts these cartridges onto devices, employing either robotic or human transfer agents.
Physical volumes are storage objects that provide an abstraction of data storage media. Physical volumes may have transient or fixed associations with devices. These associations provide a foundation to construct device and media independent storage services within the OSSI Model. The Physical Volume Library (PVL) is a storage module that creates and utilizes these associations providing the capability to execute location independent cartridge mount/dismount requests.
Stores are storage objects that provide addressing and transfer models for either physical volumes or other stores. A Virtual Storage Service (VSS) is a storage module that creates stores and builds associations between stores and physical volumes or other stores. The VSS uses these associations to translate access requests into sets of requests to the appropriate Mover(s) and, if the associated physical volume is not mounted, to the appropriate PVL.
The storage system environment encompasses the storage-system-wide management and security frameworks, and the communication, location and name services of the OSSI Model. The following paragraphs briefly describe the services provided within each of the frameworks:
Storage system management is the collection of functions responsible for control, coordination, monitoring, performance and utilization of the storage system. The VSS, PVL, PVR and Mover use common storage system management mechanisms to monitor and control storage system resources in conformance with site-specified management policies.
The security framework is the collection of functions associated with authentication of principals, authorization of principals to access storage objects and enforcement of access policies.
The communication service connects all storage modules and their respective clients.
The location service maps a Standard Object Identifier (SOID) to its abstract location in communication space.
The name service associates arbitrary, structured storage object names with object identifiers for client convenience.
Key Concepts
Transparency
The OSSI Model allows many varieties of transparency including device, location and replication transparency.
o Device transparency supports device independent programmatic interfaces.
o Location transparency eliminates the need for clients to know the actual location of stored data or services.
o Replication transparency allows clients to remain unaware that replicas of their stored objects exist.
Separation of Policy and Mechanism
The OSSI Model separates policy from supporting mechanism. For example, the OSSI Model does not specify recovery policies, but it does provide mechanisms to define, associate and execute such policies.
Separation of Control and Data-flows
The OSSI Model distinguishes control flows from data flows occurring between a client, a data source, and a data sink. Control flows carry requests, replies, and asynchronous notifications between a client and the data source or sink device. Control flows between the data source and data sink carry source-sink protocol information to manage the flow of data. Data-flows pass only from a source to a sink. By logically separating control and data flows, the OSSI Model offers the possibility of optimizing each flow through separate implementation.
Third-Party Transfers
The OSSI Model allows data to flow directly between independent sources and sinks, under the control of a third party, the initiating and controlling agent or client. Each entity separately performs operations such as data-flow control, error reporting, or initiating and terminating the transfer.
Layered Object Naming
The OSSI Model presents a uniform name space for all objects. Clients may build on this uniform naming scheme to construct arbitrary naming schemes.
Hierarchical Storage Management
The OSSI Model supports the optional creation and automated management of storage hierarchies, as well as the creation and association of policy to manage movement of data within the hierarchy. A storage hierarchy is an open storage system that provides multiple levels of service (performance, reliability, availability, etc.) and provides for movement of data among levels of service according to management policy. Examples of these policies include caching policies for movement of data to a higher-performance store, and policies for movement of data to a lower cost store.
Scalability
The OSSI Model is intended to describe open storage systems of any size. Therefore, the OSSI Model does not specify any physical size or limit. Storage system implementations, based on the OSSI Model, can use different communication, location, and naming structures for different sized implementations.
Within the OSSI Model's environment, storage system management supports system scalability with services to create storage object groups. These groups can be associated with distinct management policies allowing autonomous operation.
Distribution
The OSSI Model does not assume or specify any specific framework for distribution or centralization. Therefore, the OSSI Model can describe open storage systems that are distributed as well as centralized.
System Management
The OSSI Model prescribes a standard framework for extensible system management. This extensibility allows management of storage systems at a system level, as well as definition and imposition of policy within individual modules and storage objects.
Event Notification
The OSSI Model provides event notification services to loosely couple storage system management to the storage modules and objects. Clients may register for notifications associated with storage system events, such as a storage object state change. Modules can post information (i.e., notifications) for registered clients when these events occur. Multiple clients may register for the same notifications.
Storage Objects
Device
A device consists of a set of media access points and a set of mount points. A mount point is the mechanism used for associating a cartridge with a device, and the media access point is the mechanism used to copy data to/from media.
A media access point is the device component that copies data between loaded storage media and a communications service. The media access point performs storage operations on physical volumes. Attributes of a media access point define characteristics for physical stores such as addressability, minimum positioning granularity, and unit of data transfer.
The mount point is used to associate a cartridge with a device. When a mount point is occupied by a cartridge (mounted), it allows one or more media access points to be associated with a physical volume through a load operation.
Mount point attributes include cartridge and physical volume currently mounted, historical statistics and physical characteristics necessary to determine cartridge compatibility.
Making a physical volume available for client access requires a PVR mount operation, followed by a Mover load operation. The mount operation associates a cartridge with a mount point and, implicitly associates contained physical volumes with a device. In devices with fixed media, a permanent mount association exists for a set of physical volumes. The load operation associates one or more media access points contained in the device with a mounted physical volume, and leaves the media access points ready to access the physical volume. Mount is a PVR operation on cartridges, while load is a Mover operation on physical volumes.
The abstract device models all storage devices, including, for example, memory devices.
Cartridge
A cartridge is an abstraction of a package for a set of physical volumes or a set of cartridges. A cartridge that contains only a set of physical volumes is a base cartridge. All other cartridges are compound cartridges.
The cartridge storage object allows the management of removable media. As an implementation the cartridge is the recording media backing, the plastic shell, and whatever else is necessary to support or transport the physical volume as an independent entity. Any operation that requires the physical transport of a physical volume, is applied to the cartridge in which the physical volume(s) is contained.
Every physical volume is contained within a cartridge. Every cartridge has a location and no two cartridges may have identical locations. All physical volumes contained within a cartridge have identical locations.
A cartridge has attributes of type, life cycle state, location, purchase lot and history. The cartridge type is a collection of cartridge attributes including a form factor, load mechanism, slot shape, configuration, compounding characteristics, and durability. The cartridge type attributes, taken together, may be used to distinguish between different types of cartridges. Required cartridge attributes include: an external, human-readable cartridge name, a cartridge type, a set of location attributes (e.g., physical location, controlling PVR, node/bus address, etc.), and a cartridge identifier.
Binding forms an exclusive relationship between a base cartridge and a set of physical volumes or a compound cartridge and a set of cartridges. Within the OSSI Model, physical volumes cannot be unbound from their base cartridges. The OSSI Model allows arbitrary binding and unbinding of compound cartridges.
Physical Volume
A physical volume is an abstraction of recording medium with descriptive attributes and a set of operations that control the physical aspects of media. A physical volume defines the portion of recording media accessible through copy and position operations without intervening load operations, and is the basis for the store's addressing and transfer model. For example, the magnetic tape within an IBM3480 tape cartridge would be considered a physical volume.
A portion of each physical volume may be reserved for the PVL to implement internal volume labels. The physical volume size and read/write semantics that form the basis of a physical store shall exclude this reserved portion of the physical volume.
A physical volume is characterized by a defined set of attributes including: read/write semantics, a media type, a format type, and a physical volume identifier. The PVL maintains the association between the physical volume and the cartridge in which the physical volume is contained.
Some types of physical volume attributes represent an extensive list of descriptive information. For example, the media type attribute represents: the physical dimensions of the media, the recording density used by a compatible drive, compression algorithms employed at the device level, and the bit encoding scheme used by a compatible drive.
Clients gain access to physical stores associated with physical volumes through mount operations. The PVL converts mount operations on physical volumes to the appropriate mount and load operations on associated cartridges and devices, respectively.
Store
A store is an addressable storage space with descriptive attributes and a set of services to control data storage and retrieval.
There are two different types of stores, physical and virtual. A physical store is an abstraction defined by a physical volume's size and read/write semantics. A virtual store is a store defined by client specified size and read/write attributes. There may be many types of physical and virtual stores.
Stores are created through client interactions with the Virtual Storage Service (VSS). The Virtual Storage Service provides the service interface for stores. Clients can build associations between a virtual store and physical stores or other virtual stores through the services of the VSS.
The store has attributes that include owner, composition method, addressing and data transfer model, and service level.
Stores are allocated by the VSS. Stores may be owned by data management applications such as file systems and database managers, as well as other clients which perform data management services internally.
A client views the store as a contiguous set of transfer units. A physical store has transfer units indicative of the physical volume's media format. For disk devices, the unit is typically a sector; and for tape devices, the unit is typically a block. A virtual store has client defined transfer units.
The transfer units in a store have sequential numbers starting from zero to the maximum transfer unit number minus one. For physical stores the maximum transfer unit is device dependent. Only transfer unit numbers from zero to the maximum number minus one are valid addresses. Addressing can be absolute or relative. Absolute addressing consists of specifying a transfer unit number within a given store. Relative addressing consists of specifying a transfer unit offset relative to the previously specified transfer unit number or present location. A random access store supports both absolute and relative addressing schemes. A sequential access store only supports relative addressing and absolute addressing for transfer unit number zero.
It is not necessary to associate unused transfer units in a virtual store to an underlying store. The OSSI Model defines transfer units of a store that do not have associations with an underlying store as holes. The initial state of a transfer unit is normally a hole. The VSS creates transfer unit associations when a client writes into a corresponding hole and as management policy dictates. Clients create one or more holes by deallocating a set of underlying transfer units from associations with an overlying store. Copying from a set of transfer units that includes one or more holes returns information about the boundaries of the hole(s).
The service level of a store specifies guarantees of availability, cost, and performance. The service level may describe the guarantee in terms of an objective within a specified range. Examples of service level attributes include a list of performance boundaries such as addresses at which a discontinuity in access time occurs (e.g., cylinder boundaries) or the transfer unit size that optimizes throughput.
The structure and semantics of the store determine the set of acceptable service requests. For example, a physical store representing a tape volume may be a structured address space of variable length tape blocks and tape marks. Positioning services within such a physical store might be at the granularity of blocks and tape marks. The validity of requests may depend on the device available, as with some tape devices that support forward space by block but not reverse space.
Clients initiate data transfers through operations on stores. Clients identify a store's sub-range by a set of transfer units described within the appropriate addressing model (relative or absolute). The Virtual Storage Service decomposes data transfer requests (copy) into one or more copy requests to underlying stores by traversing defined associations.
Storage Services
Mover (MVR)
Purpose
The Mover performs operations on media access points and effects data transfer. Media access points are the means of accessing physical volumes and sections of memory accessible to Mover clients.
A Mover performs two distinct functions:
1) it changes or monitors the read/write state of a device (e.g., positioning within the physical volume, reporting status and errors, and loading and unloading physical volumes as necessary).
2) it transfers data and source/sink information (to effect the transfer of data) between devices, devices and memory, or from memory to memory.
Relationship to Other Modules
Typical clients of a Mover are the VSS, the PVL, and clients external to the storage system. Device management operations involve a single Mover, while copy operations involve one or more Movers.
Architecture
The association of a Mover and a loaded physical volume defines a client addressable storage space. The addressing model of this space depends on the semantics of the physical volume and the device addressing capabilities defined in the association.
The Mover may be positioned on a physical volume by specifying an address. A Mover may impose limitations on positioning within physical volumes. The limitations imposed by a Mover may differ from the constraints imposed by the media access point and are defined by the PVL or the Mover implementation. For example, the format of recording on the media may be specified to the Mover by its client, or may be chosen by reference to a set of defaults. Once specified, a Mover is held responsible for the recording of data in that format, including the determination of block sizes and the writing of file marks.
In a copy operation, the data flow between the media access point and the communications service is managed by the Mover (see Figure 3). The data may or may not pass through the Mover during a copy operation. Data may flow directly between media access points under Mover control.
An implementation may merge instances of Movers into larger entities which optimize internal data-flows.
Within either the source or sink media access point, data may undergo arbitrary transformations such as encryption or compression, by hardware or software. From within the OSSI Model, such transformations appear only as different media types, and appear as attributes of both the media and the media access point. Clients instruct the Mover to set these attributes, and supply the necessary parameters, such as selected compression algorithm or required encryption key.
The copy operation allows for client-selectable classes of service (e.g., block size, order and parallelism of data delivery, etc.). While remaining consistent with client requirements, Movers are free to manage communication services, including breaking transfers into smaller units, aggregating transfers into larger units, reordering the sequence of transmission of parts of transfers, using single or multiple channels, etc. Such internal management by Movers is invisible to the client, and is undertaken by Movers only in the interest of meeting the service expectations of clients.
Services
The Mover interface provides clients with the ability to manipulate media access points and effect data transfer operation. The services provided at the Mover interface include:
set/show attribute(s)
Write or retrieve the values of specified attributes on media access points or query the status of a media access point or media access point-physical volume association. The status of a media access point may be queried at any time. Status may include such items as whether a physical volume is loaded, attributes of the physical volume (e.g., size, recording format, density, etc.), attributes of the media access point (e.g., encryption, current position in the address space, etc.), and performance data (e.g., total errors, recovered errors, count of transferred bytes, etc.). Note that some devices are incapable of reporting certain status, for example, a continuous tape loop does not support the concept of current position. The Mover may limit client changes to certain attributes based on the current state of the media access point.
load/unload
Associate a mounted physical volume with a set of media access points. The Mover must load a physical volume before the Mover can provide any positioning or copy services. Similarly, a physical volume may be disassociated from a set of media access points in preparation for dismounting.
position
Position a media access point to a specific address within the physical volume. The physical volume-media access point association presents an address space exported by the Mover. Positioning within this address space involves the actions needed to ensure that the next copy operation commences at the client specified address (subject to addressing limitations). Some devices cannot support all positioning, such as positioning backward from the current position.
copy
Copy data from a source Mover to a sink Mover. A source (sink) Mover reads (writes) data from its associated physical volume (memory, media, etc.) at a specified or current position. Source and sink Movers may be the same. Any attempt to perform a copy at addresses either outside the areas permitted to the client, or outside the physical limits of a device are rejected.
Copy requests may be rejected for other reasons (e.g., an attempt to copy to a volume with a read-only attribute, or to write at an internal position on a volume with an append-only attribute). Copy services may return ending status, or may leave such status to be determined through subsequent query requests.
One or more source Movers may be used to generate a data stream, or a data stream may be transmitted to one or more sink Movers by optionally specifying multiple sources and sinks. Additional options may allow sequential or parallel delivery of data.
partition
Restrict or remap the address space of the loaded physical volume. A Mover may place limitations on the generality of this partitioning capability. The purpose of the partition command is to protect portions of the physical volume, and to allow sharing of the physical volume.
synchronize
Commit any received data to the associated physical volume. Committed data may or may not involve a physical write. However, any status reported by a query after a synchronize operation reflects the status of the Mover, the device, the media access point, and the associated physical volume as if a write had actually occurred.
mark (device specific)
Write device specific out-of-band data for later detection and for positioning.
Physical Volume Repository (PVR)
Purpose
The PVR forms and destroys mount associations between cartridges and mount points in devices. The PVR also injects and ejects cartridges into and out of the PVR domain. During an inject operation, a cartridge passes through an inject port at a known location and enters the PVR domain. During an eject operation, the cartridge exits the PVR domain through an eject port at a defined location.
An implementation of a PVR may employ any manual or automated physical mechanisms to perform its functions. The abstract PVR functions are independent of any particular physical instantiation. Although forming mount associations between cartridges and mount points in devices is the typical purpose of the PVR, a PVR implementation is not required to contain mount points. In this case, the PVR functions only as a repository for stowing cartridges.
The PVR employs a transfer agent to effect associations between cartridges and mount points, but the control of the transfer agent is hidden within the PVR abstraction. Effecting associations between cartridges and mount points typically requires movement of an object from one position to another. A PVR abstracts the details of both end points of the move, while naming the two objects that are to be associated (e.g., the cartridge and the mount point in a device). By hiding the cartridge storage position and device mount point position, PVR implementations are free to optimize mount associations, including staging areas, floating home positions, and mobile drives, etc.
Relationship to Other Modules
The typical client of the PVR is the PVL.
Architecture
The PVR is a module that manages individual objects (cartridges, ports, slots and transfer agents) and object groups (media and device domains). Figure 4 depicts the component objects and relationships. Media domains are sets of cartridges, and device domains are sets of mount points. A PVR is associated with a set of media domains, a set of device domains, and a set of ports. Some transfer agent(s) transparently form associations between these objects.
The Physical Volume Repository
The PVR is an abstract object and may be implemented in different ways. For example, an implementer may configure two distinct cartridge storage spaces, with separate transfer agents and a shared port, as either one or two PVRs. An implementation may also consist of a partitioned physical storage area with a single transfer agent representing two abstract PVRs.
Policy Management
Device Domains
A device domain is a set of mount points that have equal attributes and are interchangeable in forming a mount association with a cartridge. Device domains are disjoint sets of device mount points that partition the set of all device mount points associated with a single PVR. Every mount point is contained within a device domain. Device domain attributes include management policies, compatible cartridge and media types, and availability.
Media Domains
A media domain is a set of cartridges that are interchangeable with regard to forming mount associations between any member cartridge and any mount point within a compatible device domain. Media domains partition the set of all cartridges associated with a single PVR. Each media domain has a capacity that represents the number of internal storage locations (slots) within the PVR reserved to house members of the media domain.
Clients may move cartridges between compatible media domains. Media domain attributes include capacity, compatible device domains and the observed mount time for each such device domain, device domain selection policy (e.g., round-robin or least-time-to-mount), cartridge type, media type, full and depleted warning levels, occupancy, compatible ports, and availability.
Ports
A port is a path between the interior of the PVR and its environment. Cartridges enter and exit the PVR via ports. The attributes of a port include inject or eject capability, availability, capacity, and location. The location attribute defines where cartridges are located for an inject operation into the controlled space of the PVR, and where cartridges will be located after an eject operation. A PVR without a port does not have the ability to inject and eject cartridges.
Services
The PVR interface provides clients with the ability to manipulate cartridges, as well as operate on PVRs. The services provided at the PVR interface include:
mount/dismount
Associate or disassociate a cartridge with a mount point contained within a device. Mounts may be deterministic or nondeterministic. Deterministic mounts are mounts where both the mount point and the cartridge are specified. Nondeterministic mounts cause the automatic selection of either the cartridge or the device, or both, from a compatible set (e.g., scratch/device pools). The client subsequently identifies the physical volume or device via interaction with the Mover and may update the PVR internal state.
The client may request a read-only mount, which causes implementation, cartridge, or device dependent action to prevent all Mover clients from changing data stored on the physical volumes. Implementation of a read-only mount operation is optional.
bind/unbind
Form or break an exclusive relationship between a given compound cartridge and a contained cartridge.
inventory
Perform operations that attempt to synchronize the internal state of the PVR with its physical state. This state information includes the state of each cartridge and its relationship with media domains and mount points. Subsets of PVR objects may be inventoried independently.
enter/inject
Transfer the cartridge from the location of the inject port into the associated PVR (enter) and create the corresponding internal PVR state (inject). Inject or enter may fail due to cartridge name conflicts, occupancy conditions, etc. A cartridge is available for use when it has been both entered and injected.
eject
Atomically transfer the cartridge outside the associated PVR to the location of the eject port, and delete the corresponding internal PVR cartridge state.
acknowledge mount
Acknowledge that a non-deterministic mount has completed successfully by reporting the cartridge and associated mount point. The PVR updates its internal state.
set/show attribute(s)
Write or retrieve the values of specified mount point attributes. The status of a mount point may be queried at any time.
stage
Perform implementation dependent optimizations to potentially reduce execution time for a future mount command. Either a specific cartridge or a set of interchangeable cartridges (e.g., a scratch pool) may be specified.
relocate
Transfer a cartridge to another media domain.
Physical Volume Library (PVL)
Purpose
The PVL provides location independent media services for its clients. The PVL guarantees media identification and integrity, and provides a mechanism that ensures that all media services are authorized.
Relationship to other Modules
A PVL is a client of both the PVR and the Mover. The primary client of the PVL is a VSS. However, the PVL supports other clients desiring direct access to physical volumes.
Architecture
To provide location-independent media services, the PVL permits its clients to gain access to, and physically manipulate, media without requiring the client to have any knowledge of the media's physical or logical location. The location-independent media services include mounting, dismounting, importing, and exporting media. Although the bulk of PVL functionality concerns removable physical volumes, the PVL also manages non-removable physical volumes.
To guarantee media identification, a PVL requires that all physical cartridges bear a human readable, external label that contains a cartridge identifier. A cartridge identifier is unique within a PVL. Further, physical volumes within the PVL's purview are also uniquely identified.
The PVL verifies that the correct physical volume has been mounted. Typically, this service is performed by reading the internal volume label recorded on the physical volume.
The PVL utilizes physical volume and cartridge attributes to locate media without requiring client supplied location information. The location information accessible by a PVL includes the identifier of the PVR controlling the media. A PVL may permit clients to reference and operate on media using client supplied names.
A PVL collects statistics and maintains attributes of the media within its purview. Example statistics collected by a PVL include accounting statistics, performance statistics, and usage statistics.
Services
The services provided at the PVL interface include:
create/delete
Define or eliminate an instance of a physical volume or cartridge.
set/show attribute(s)
Write or retrieve the values of specified attributes associated with physical volumes or cartridges.
assign/release
Allocate or deallocate the specified physical volume(s) to the requesting client. Policy determines if and when a ``released'' physical volume is available for reassignment.
import/export
Places the specified physical volumes into or removes the specified physical volumes from the control of the PVL.
Appropriate cartridge and physical volume associations are created by the importing PVL. A cartridge identifier must be associated with each cartridge entered into a PVL's purview. The form and content of the cartridge identifier is controlled by the PVL.
initialize
Set the read/write semantics and size of the physical volume. Initialize may write an internal volume label on the physical volume.
mount/dismount
Atomically make one or more physical volumes available to the requesting client for read/write and control services. A mount operation may identify a specific physical volume to be mounted or may specify a group of one or more physical volumes from which the PVL selects the most ``appropriate'' physical volume to satisfy the request.
Dismount causes the disassociation of the physical volume from the device such that read/write and control services on the physical volume are no longer available to clients.
scratch
Places a specified physical volume(s) into the scratch state and makes an initialized or released physical volume available for assignment to a client. Site-dependent policy dictates conditions a scratched physical volume must meet before it can be reused. For example, security considerations may require that a physical volume must be degaussed before it can be reused.
Virtual Storage Service (VSS)
Purpose
The VSS controls and manages stores on behalf of its clients. Control services represent those services supported directly by stores including functions that control transfer of data. The VSS provides access to additional services to manage stores and their inherent associations with other stores, devices and physical volumes. Clients of the VSS receive an abstract view of storage and are insulated from storage hardware and physical volume reconfigurations.
Relationship to Other Modules
The VSS presents the highest level abstraction to clients of the storage system and is intended to be the most common entry point to the storage services of the system. Typical clients of the VSS include database managers, filesystems and other VSS implementations. Allotment of space from a store to client objects and the management of free space on a store is the responsibility of VSS clients. VSS clients can use VSS mechanisms to support client policies for the sharing of space within a store and management of concurrent access to stores.
A Virtual Storage Service can become a client of one or more Movers or VSSs to carry out operations on a store. For example, a VSS implementation may require interaction with peer VSS implementations for coordination purposes. A VSS becomes the client of a PVL to mount a physical volume.
Architecture
The VSS architecture provides a convenient structure to manage stores and their relationships with other stores, physical volumes and Movers.
The VSS manages the mappings inherent in virtual stores by converting client requests into a set of operations on one or more underlying stores. These operations result in appropriate physical volume or Mover requests. The mappings between stores provide the information to translate addresses of a virtual store into a set of addresses of underlying stores (Figure 5). If all underlying stores, including physical stores, are managed by a given VSS implementation, then that VSS can optimize all translations internally. The composition schemes offered by a given VSS implementation can impose strict constraints on the execution of the individual Mover requests.
The VSS responds to client requests in a manner that attempts to give desired performance while making the best use of the storage system and communication resources. For example, the VSS could expedite data transfers for physical volumes that are already mounted, increase the priority for small data transfers, limit the number of concurrent large transfers, or use a client-specified priority.
Addressing and Transfer Formats
The VSS supports a standard representation of virtual and physical stores to facilitate the interchange of stores between heterogeneous VSS implementations. Standardized methods for describing the addressing and data transfer models facilitate the mapping to underlying stores or Mover operations.
Virtual Store Composition
The VSS constructs virtual stores from composition units, which are sets of transfer units of underlying stores. By defining the basic unit of transfer for the new virtual store the VSS creates entities that may be mapped to the transfer units of existing stores. Since transfer units may be of length n bytes, where n is a positive, nonzero integer, the VSS provides clients with a rich mechanism for composing abstract stores. VSS implementations may need to constrain the allowable mapping options to manage application complexity and available computing resources. For example, policy may dictate that a given set of transfer units for a store can be mapped into only one virtual store at any given time to prevent copies into two distinct virtual stores from changing the same physical storage location.
By recursive composition, clients can use the VSS to compose a hierarchy of stores, with each hierarchical level supporting desired characteristics such as granularity of access, speed, reliability, cost, and convenience. Cycles in the composition graph are disallowed. Composition schemes that require processing of data, such as parity generation, and physical configurations that limit data path flexibility can require that data be processed internally by the VSS.
Composition schemes include concatenation, replication, striping, and various RAID methods. Concatenation involves composing a new virtual store by sequentially appending a set of existing stores (Figure 6). Replication maps one store onto the identical addresses of other stores. Striping maps a store to an underlying store to achieve parallel data transfers. RAID maps virtual stores onto underlying stores to achieve higher reliability and availability than that provided by the underlying physical volumes.
Policy Management
Storage groups are arbitrary sets of stores, or storage groups managed as a unit. Security, administration, and composition policy can be associated with all stores of a storage group. A storage group is a set of stores defined by an exclusive relationship such that no store is contained in more than one storage group.
Services
The services provided at the VSS interface include:
create/delete
Define or eliminate an instance of a store or storage group. Create defines a new store and associates specified attributes such as addressing model, transfer unit size and level of service.
set/show attribute(s)
Writes or retrieves the values of specified attributes on stores.
open/close
Register an optimization hint that a store or storage group will be accessed or no longer accessed. The VSS may perform implementation dependent actions including loading or clearing store mapping tables, caching authorization information, setting up or clearing internal locks for serialization or intent, or performing operations on subordinate stores. Open/Close on physical stores, and storage groups that include physical stores, may generate PVL mount and dismount requests on physical volumes as appropriate.
copy
Transfer data between stores. A store is either the local memory store or an external store. Local client address-spaces are treated like stores for the purpose of data transfer. Data transfer functions support traditional data transfer and third-party transfer protocols. Data transfer functions decompose requests into sub-requests for underlying stores for this or other modules. When data transfer functions involve physical stores, PVL and Mover services are requested as necessary.
synchronize
Commit all volatile data and metadata to the associated persistent storage.
map/unmap
Create or delete an association between a store and an underlying store. The map/unmap services can also be used for replacing failed stores and rebuilding data from redundant stores onto new stores.
import/export
Atomically transfer the specified store or storage group into or out of the storage system domain.
associate metadata
Add, delete, retrieve, or replace metadata for stores or storage groups. Stores and storage groups may have metadata associated with them to support various functions such as load balancing, migration, and auditing.
list
Return a list of stores or storage groups, and their attributes, that are available to form new virtual stores.
lock/unlock
Lock or unlock a storage group, store, or set of transfer units of a store. Locks can be of various types, including read, write, intention, etc.
group/dissolve
Create or delete a storage group association.
Storage System Environment
Introduction
The open storage system framework described by the OSSI Model depends on a number of services from the surrounding computing environment which are not specific to storage systems and are therefore not defined by the OSSI Model. These services are necessary to instantiate the OSSI Model as an implemented storage system domain. Detailed standards for the interaction of storage modules with the environment will be required to support interoperability.
Storage System Domains
A collection of open storage systems may be partitioned into distinct domains.
A communications domain is the set of objects that the communications service can communicate with by name.
An administrative domain is the set of objects managed by a single administrative authority under a common administrative policy.
A security domain is the set of objects whose access is controlled by a common security protocol and associated security policy.
A storage system domain is the intersection of a communications domain, an administrative domain, and a security domain. The storage system domain would then be subject to a single coherent security and administrative policy with the necessary communications infrastructure. The storage system domain is the domain in which the individual open storage systems interact to carry out useful functions. The storage system domain includes all clients and all storage modules in the OSSI Model, as well as their contained storage objects.
Storage System Management Framework
Purpose
The storage system management framework provides the structure in which storage system resources can be monitored and controlled in ways that conform to site-defined management policies. Policies may be an intrinsic part of a storage module in which case the role of storage system management is performed within the module. When policies are extrinsic, a storage module must communicate with independent management services to comply with policy. The storage system management framework does not mandate specific management roles and rules, but rather provides an extensible structure in which to implement and enforce site-specific storage system policy and procedure.
Storage System Management (SSM) is composed of a set of functions that enable and facilitate the control, coordination, monitoring, optimization, and utilization of the storage system. Storage system management must support the exchange of management information with storage modules, and control system resources in consistent and predictable ways. Since site requirements and policies are likely to change over time, storage system management must be adaptable.
The storage system management framework provides for the coordination of OSSI modules, and intrinsic or extrinsic management processes (Figure 7).
SSM can control and monitor all defined objects in the storage system domain. SSM performs management operations through the storage module interfaces in order to set and query object attributes, request specific object operations, and receive asynchronous notifications of significant events within storage modules.
SSM relies on existing security services in the environment to prevent unauthorized access to storage objects or storage modules. It also relies on the environment's communication services to perform object or attribute operations and to receive notifications.
Relationship to Other Standards
The OSSI Model's storage system management framework is based on the ISO OSI management model as defined in a collection of international standards, including:
OSI Management Framework, ISO/IEC 7498-4, 1984
Systems Management Overview, ISO/IEC 10040, 1991
Structure of Management Information Model, ISO/IEC 10165-1, 1991
Guidelines for the Definition of Managed Objects (GDMO), ISO/IEC 10165-4, 1991
Besides OSI management concepts, the OSSI Model's management framework also relies on storage module interactions with policy objects to provide a basis for distributed system implementations of management procedures and site policy enforcement.
The OSI management model structures a managed system in terms of managed objects, their attributes, the management operations that can be performed on them, and the notifications that they can emit. A collection of management data called the management information base contains the current state of the managed objects in the system. Management activities take place through interactions among management processes, agent processes and managed objects [Figure 8]. A management process issues operations to agent processes, including requests for information and actions to be performed on managed objects. An agent process interacts with a management process by sending notifications to the management process, either synchronously, as a result of an operation, or asynchronously, reporting an event that has taken place.
Policy Objects
The purpose of policy objects is to provide a mechanism to define and associate specific management policies with a storage system object (storage object or storage module) or identifiable groupings of objects. Policy objects are managed objects that contain authorization and motivation information about who is allowed to do what to whom, when, and why. Implementations of policy objects may have well-defined data structures and methods associated with them to provide useful information, in the form of returned values, to clients of the policy object. Policy objects may be required to use management information contained in other managed objects, as well as their own data, to make decisions. Policy objects, together with the management data they use, provide the means for policy-driven administrative optimization of storage system behavior.
Object Groups
There are likely to be many situations where specific site policies must apply to more than one storage system object. To meet this need, the concept of an object group provides the capability to efficiently and consistently apply a policy to several storage system objects of the same type. Some examples of object groups in the Model are storage groups and media domains. Object groups may be implemented in different ways. An object could have an attribute that identifies the group to which it belongs, or alternatively a new object could be created that represents a specific collection of objects.
Services
The services supported within the storage system management framework include:
Fault Management
Monitor, detect, isolate, and correct abnormal operations and modules of a storage system. Fault management includes the ability to detect latent errors through verification procedures, to create, maintain, and examine error logs, and to take proper action upon detection of errors. A major task of fault management is the recovery of stored data from failing components of the Model. Fault management uses storage module services to analyze, display and modify metadata of storage objects, to copy recoverable data to different storage media, and to update containment information as required.
For example, as part of fault management services the storage system would provide backup and recovery functions that assist in maintaining the integrity of storage system information. Programs would be available to back up stores, critical dynamic tables and data bases, and to restore data from those backups. In cases where no backup of damaged media exists, every attempt would be made to recover all readable data. Necessary notifications and cleanup operations would be provided for any unrecovered data.
Configuration Management
Support the initialization, operation, and shutdown of the storage system by maintaining the topology of storage system resources. Configuration management also monitors and controls installation and removal of physical resources, and reports on the current state of installed resources.
For example, historical data can be used to determine the amount of free space to keep available for each store. Periodically a management process could automatically reconfigure the stores that do not meet the free space criterion (e.g., via migration of inactive transfer units).
Security Management
Set and enforce security policies for storage resources. Detect and report security policy violations. Security management may maintain logs that record attempted security violations and all storage system requests that are of security interest.
Accounting Management
Record resource usage and enforce resource usage policy. Accounting Management provides the mechanisms to charge accounts for resource usage and to deny storage resources to overdrawn accounts. Charges may be incurred for the use of any storage system resource, including such typical resources as bytes stored, data transferred, volumes mounted, and desired quality of service.
Performance Management
Measure, predict, and optimize storage system performance over time. Efficient and cost-effective storage system utilization is accomplished by monitoring performance indicators such as response times, resource utilization, demand and contention, and queue lengths. This data can be used to change the system configuration, balance requests among modules, change module implementations (e.g., connectivity, distribution, replication), and plan for future demand.
For example, to maintain performance the storage system could automatically control fragmentation and recover wasted space. Defragmentation may be performed intrinsically by a VSS, or may be realized through an extrinsic management application such as a specialized migration manager.
Transaction Management
Provide a consistent view of critical system tables and databases in the presence of multiple concurrent changes. For example, if saving data to a store modifies an object attribute and updates a directory that points to the attribute, the set of operations should be performed atomically.
Security Framework
To accommodate a broad range of security implementations, the OSSI Model defines a security framework. Storage system modules act within this framework on behalf of principals. A principal is a human client for which the open storage system carries out actions. Principals have identities with associated rights. The security framework consists of the following three services:
Authentication
Establish the identity of a principal. The authentication process also establishes the principal's attributes (e.g., role, security label, group membership, etc.). The authentication process is embedded in the communications service.
Authorization
Establish the rights and restrictions of a principal relative to a storage object. An implementation may use whatever mechanism desired, including access control lists or capabilities.
Enforcement
Verify whether an operation on a storage object is allowed relative to the authorization a principal has for the storage object. If the operation is allowed, it is performed and the appropriate reply is returned.
All three services are logically independent and may be separately implemented with the output of each used as the input of the next.
Every storage object (i.e., every object with a SOID) may potentially have access control applied to it. Storage system security policy determines the application of access control to storage objects.
Communication Services
Communication services provide the mechanism for all storage modules to communicate with each other. The OSSI Model assumes that all storage modules are fully connected by communication paths.
The communication services are modeled after the ISO OSI reference model where any services required for communicating between a source-sink, or client-module that are described in the OSI model are allocated to the communication services. This places source-sink coordination for data transfers within the communications framework. By describing the communications services as those services defined in the OSI reference model, a specific topology or communications framework is not explicitly specified. The reference to the OSI reference model is merely to identify the scope of the communication services in the environment.
Location Services
The location service maps a SOID to its abstract location in communications space. A given storage object has a unique location in this communication space and is accessible through an associated storage module. The location service transparently obtains the relevant storage object location and responds to the requester with that location.
Storage object creation and location registration is a single atomic operation in the OSSI Model, as is storage object deletion and location deregistration. Whenever a module creates an storage object, a SOID is generated to identify the storage object. This SOID is transparently registered with the location service at the module, and the location service updates whatever location information an implementation may need in order to send requests to objects. Whenever a module deletes a storage object, the location service at the module is informed of the deletion of the storage object. Communication addresses are not visible to storage modules.
There is no requirement that every object in the storage system domain be visible to every module or to every client. The visibility of object SOIDs depends on the semantics of the individual objects. For example, store SOIDs are visible throughout the storage system domain, while transfer unit SOIDs need be visible only to a specific client of the VSS.
Name Services
A name service maps an object specification of arbitrary structure to one or more standard object identifiers (SOIDs). A name service implements an access structure on the uniform name space of OSSI Model SOIDs. The choice of a particular name service architecture is typically determined by the syntactic and semantic requirements for the name space. The object specification may be as common as a file path name in a hierarchical directory structure, or as exotic as a query of arbitrary complexity in a relational database. The file path name typically returns a single SOID, while a database query might return a list of SOIDs.
Name services are completely optional in a storage system. Some security environments may require clients to use a name service to enforce a specific security view of the storage system. In these environments, the name service may return security authorization information as well as SOIDs.
REFERENCES
[ANSI X3.27] American National Standard Magnetic Tape Labels and File Structure for Information Interchange, American National Standards Institute, ANSI X3.27 (1978)
[CORBA] The Common Object Request Broker: Architecture and Specification, Revision 1.1, Object Management Group, Document 91.12.1 (1992)
[ECMA 167] Volume and File Structure of Write-Once and Rewritable Media Using Non-Sequential Recording for Information Interchange, European Computer Manufacturers Association, ECMA 167 (1992)
[IBM Labels] MVS/ESA Magnetic Tape Labels and File Structure Administration, Version 3, Release 1, IBM SC26-4511-2 (1991)
[ISO/IEC 1001] Information Technology -- Magnetic Tape Labeling and File Structure for Information Interchange, ISO/DIS 1001 (1979)
[ISO/IEC 7498-1] Information Technology -- Open Systems Interconnection -- Basic Reference Model, ISO/IEC 7498-1 (1984)
[ISO/IEC 7498-4] Information Technology -- Open Systems Interconnection -- Basic Reference Model -- Management Framework, ISO/IEC 7498-4 (1984?)
[ISO/IEC 9595] Information Technology -- Open Systems Interconnection -- Common Management Information Service Definition, ISO/IEC 9595 (1991)
[ISO/IEC 10040] Information Technology -- Open Systems Interconnection -- Systems Management Overview, ISO/IEC 10040 (1991)
[ISO/IEC 10165-1] Information Technology -- Open Systems Interconnection -- Structure of Management Information -- Part 1: Management Information Model, ISO/IEC 10165-1 (1991)
[ISO/IEC 10165-4] Information Technology -- Open Systems Interconnection -- Structure of Management Information -- Part 4: Guidelines for the Definition of Managed Objects, ISO/IEC 10165-4 (1991)
[OMAG] Object Management Architecture Guide, Revision 2.0, Object Management Group, Document 92.11.1 (1992)
GLOSSARY
Absolute Addressing
The offset from the first transfer unit in the store. A transfer unit has an address between 0 and the maximum transfer unit number - 1.
Accounting Management
A mechanism to record resource usage and enforce resource management policy.
Administrative Domain
The set of objects managed by a single administrative authority under a common administrative policy.
Agent Process
A process capable of providing management services for managed objects and of emitting notifications on behalf of managed objects.
Authentication
Verification of the identity of a principal.
Authorization
The determination of object services that a principal is authorized to request.
Base Cartridge
A cartridge that contains only a set of physical volumes.
Caching
A type of migration in which a virtual store is remapped to a store that provides higher performance characteristics.
Cartridge
A storage object consisting of either a set of physical volumes or a set of cartridges.
Communication Service
The mechanism through which all storage modules communicate with each other.
Composition Scheme
The process the Virtual Storage Service uses to map a store's address space to other stores. Composition Schemes include concatenation, replication, striping, and various RAID methods.
Composition Unit
A set of Transfer Units used as a basic building block for constructing stores from underlying stores.
Compound Cartridge
An object consisting of a set of cartridges.
Control Flow
The flow of requests, replies and asynchronous notifications between the client and the data source and sink.
Controlling Agent
The process that controls the transfer of data between a source and sink.
Data Flow
The movement of data between a data source and a data sink.
Defragmentation
The repositioning of transfer units in a store to maximize the contiguous unallocated space.
Device
A set of media access points and a set of mount points.
Device Domain
A set of devices and their contained mount points that have equal attributes and are interchangeable in forming a mount association with a cartridge.
Device Transparency
Client access to devices via a device independent programmatic interface.
Enforcement
The determination of a principal's ability to perform an operation on an object based on the principal's authorization relative to an object.
Event
An occurrence relative to a storage module or contained object. Requests, responses and changes of state are types of Events.
Fault Management
The monitoring, detection, isolation and correction of abnormal occurrences within storage modules.
Floating Home Position
A PVR performance optimization which allows a cartridge's home slot to change after operations such as dismount and inventory.
Holes
Transfer units of a store which are not mapped to an underlying store.
Life Cycle
The collection of states and permitted state transitions that a storage object goes through during its' life in a storage system.
Location Independence
A service is location-independent if the requesting client is not required to supply the location of the storage module that supplies that service.
Location Service
The service that maps a SOID to its abstract location in communication space.
Managed Object
An abstract management view of a system resource that may be managed through the use of management and agent processes.
Management Process
A process capable of issuing management operations to and receiving notifications from managed objects via an agent process.
Media Domain
A set of cartridges that are interchangeable with regard to forming mount associations between any member cartridge and any mount point within a compatible device domain.
Media Type
A set of physical volume attributes including the physical dimensions of the media, the recording density used by a compatible drive, compression algorithms employed at the device level, and the bit encoding scheme used by a compatible drive.
Metadata
State information consisting of three types.
1. Intrinsic persistent properties of objects required by the methods.
2. Transient state of an object.
3. Attributes for component objects that interact.
Migration
The remapping of a virtual store to a different underlying store.
Migration Management
The policies set by system administrators for remapping virtual stores from one type of store to another.
Mount Point
A cartridge storage slot that, when occupied, allows one or more media access points to be associated with a physical volume.
Mover
The storage module responsible for copy services on storage media. A Mover also provides services to change and monitor the read and write state of a single device.
Name Service
The service that provides naming indirection to support arbitrary, structured object names for client convenience.
Notification
A piece of information sent from one object to another object independent of a normal operation request.
OSSI
The acronym for Open Storage Systems Interconnection.
Object Group
A generalized type of object set whose membership is defined by an exclusive relationship.
Object Identifier
See Standard Object Identifier.
Object Instance
A single occurrence, instantiation, of an object type. For example, Volume ABC123 represents an instance of the object type physical volume.
Open Storage System
Mechanisms that comply with the requirements of OSSI standards which are necessary to store and retrieve a stream of bits.
PVR Domain
The collection of a physical cartridge repository, mount points within devices, and transfer agents that may be used to form a mount association between cartridges and mount points in devices.
Partitioned Physical Storage Area
A physical storage area that is divided into distinct sub-areas. Each distinct sub-area functions as though it were physically separate from the other sub-areas. The distinct sub-areas of the physical storage area are disjoint.
Performance Management
A set of management services concerned with the measurement, prediction, and optimization of storage system performance over various time scales.
Persistent Storage
Storage whose contents are enduring and are not subject to modification or loss when electrical power is disconnected.
Physical Store
An abstraction of the physical volume. The physical store is managed by the Virtual Storage Service such that all operations on physical stores are requested through the Virtual Storage Service.
Physical Volume
An abstraction of storage media that is constrained to encapsulate the storage media associated with a single physical store. The physical store is defined by the range of valid copy and position requests accepted by a Mover without an intervening load request.
Physical Volume Library (PVL)
The storage module that executes location independent mount and dismount requests.
Physical Volume Repository (PVR)
The storage module responsible for storing removable media containers called cartridges and for mounting these cartridges onto devices, employing either robotic or human transfer agents.
Policy
A course of action, guiding principal, or procedure, considered expedient, prudent, or advantageous, that governs aspects of a storage system such as access control and migration management.
Port
A path between the interior of a PVR and its environment through which cartridges are injected and ejected.
Principal
The entity for which a storage module performs services.
RAID
The acronym for Redundant Array of Independent Drives. RAID is a composition scheme that maps virtual stores onto underlying stores to achieve higher reliability and availability than is provided by the underlying physical media.
Random Access Store
A store that supports both the Relative and the Absolute Addressing schemes.
Relative Addressing
An addressing scheme that consists of specifying a Transfer Unit offset relative to either a previously specified Transfer Unit or to the present location.
Removable Media
Media that can be physically removed from storage devices. Magnetic tape is an example of removable media. Hard disk is an example of nonremovable media.
Replication
A composition scheme that maps the complete address space of a virtual store onto multiple underlying stores.
Replication Transparency
An architectual feature that allows clients to remain unaware that replicas of their data are being stored and synchronized.
SOID
The acronym for Standard Object Identifier.
Scratch State
The operational state of a physical volume that is not assigned to any client and either has never been used or has been reprocessed for reuse.
Security Domain
A set of objects whose access is controlled by a common security protocol and associated security policy.
Security Framework
The collection of functions, associated with authentication of principals, authorization to access objects, and enforcement of access policies.
Security Services
Authentication, authorization and enforcement of access to, and operation on, a storage object.
Sequential Access Store
A store that supports the Absolute Addressing scheme only for Transfer Unit number 0. Otherwise, a Sequential Access Store supports only the Relative Addressing Scheme.
Sink
The place to which data involved in a data transfer operation is written.
Source
The place from which data involved in a data transfer operation is read.
Staging Area
An area where cartridges can be placed to potentially reduce the execution time of expected future mount services. Movement of cartridges to a staging area is accomplished via the Stage command.
Standard Object Identifier (SOID)
A logical tuple composed of a <type, ID> pair that uniquely identifies an externally visible object in the OSSI Model. The type defines the format of the ID portion of the tuple. The ID uniquely identifies the object instance.
Storage Group
An arbitrary set of stores managed as a single unit. No store is contained in more than one Storage Group.
Storage Hierarchy
An open storage system which provides multiple levels of service (performance, reliability, availability, etc.) and provides for migration of data within the system in accordance with migration management policy.
Storage Media
Various forms of physical material suitable for having data written to it. Examples of Storage Media include magnetic tape, magnetic disk, and optical disk.
Storage Object
Abstractions which represent the fundamental mechanisms within storage systems. The OSSI Model identifies devices, cartridges, physical volumes, and stores as storage objects.
Storage System Domain
The intersection of a communications domain, an administrative domain, and a security domain.
Storage System Environment
The collection of storage management and security frameworks, and the communication, location and name services needed to support the OSSI Model.
Storage System Management
The collection of functions charged with control, coordination, monitoring, performance, and utilization of the storage system.
Store
An addressable storage space. A store is defined by descriptive attributes (e.g. describing an addressing and data transfer model) and an associated set of services that control data storage and retrieval.
Store Recovery
The ability to recover stores from bad or damaged physical media.
Striping
A composition scheme that maps a store to an underlying store in such a manner as to achieve parallel data transfers.
Third-party Transfer
The transfer of data between independent source and sink devices under the control of a third-party. Third-party transfers completely separate the controlling entity from the source and sink.
Transfer Agent
The mechanism by which a cartridge is mounted onto a device. A Transfer Agent may be either robotic or human.
Transfer Unit
The basic unit used for the transfer of data to and from stores. For example, a transfer unit for a disk may be a sector and for a magnetic tape may be a block.
Virtual Storage Service (VSS)
The storage module responsible for providing mechanisms to compose stores from discretely addressable storage spaces and to translate client access requests to these stores into sets of requests to the appropriate Mover(s) or PVL if the associated physical volume(s) are not mounted.
Virtual Store
A store that is mapped to a physical store or to another virtual store through the services of the Virtual Storage Service.