HP OpenVMS System Manager's Manual, Volume 1:... |
Managing Storage Media |
|
|
|
| |
Understanding Storage Media Concepts
| Term | Definition |
|---|---|
|
Device (or Drive )
|
Hardware that allows access
to storage media.
|
|
Media
|
Physical items on which
you can store data.
|
|
Volume
|
Logical unit of data storage; one or
more media units. A disk or tape must be mounted on a device for
the operating system to recognize it as a volume.
|
The following sections use these terms to explain media concepts.
Disk and CD-ROM Concepts ![]()
This section defines terms related to disks and CD-ROMs. It
also compares on-disk file structures and explains the ISO 9660
standard.
Disk Terminology ![]()
Disks are
physical media on which files reside. On-Disk Structure (ODS)
refers to a logical structure given to information stored on a disk;
it is a hierarchical organization of files, their data, and the
directories needed to gain access to them. The OpenVMS file system
implements the ODS and provides access control to the files located
on the disk.
Compact disc read-only memory (CD-ROM) discs and readers used with computers are very similar to the CD-ROMs used for audio applications. The major differences are that CD-ROM drives have a digital (rather than an audio) interface, and that CD-ROM discs employ additional layers of error correction and formatting to encode data blocks.
The advantages of storing data on CD-ROMs rather than on tape or other removable media are:
Disk and CD-ROM Terminology defines terms as they apply to disks and CD-ROMs.
| Term | Definition |
|---|---|
|
Sector
|
Uniquely addressable unit.
Each sector on a CD-ROM comprises a sequence of 2048 8-bit bytes;
on most disks, a sector is equivalent to a block (512 bytes).
|
|
Logical
block
|
Organizational unit of volume
space containing 512 8-bit bytes. A CD-ROM sector comprises 4 blocks.
|
|
Logical
block numbering
|
Logical blocks are numbered
from 0 to n-1.
|
|
Cluster1
|
Logical grouping of blocks;
basic unit by which disk (not CD-ROM) space is allocated.
|
|
Extent
|
Contiguous logical blocks
allocated to a particular file.
|
|
File
|
Array of consecutive virtual
blocks2,
numbered 1 to n, plus a set of attributes with values.
A file is either a data file or a directory file. Directories can
contain both data files and directory files.
|
|
Volume
|
Disk that has been prepared
for use by placing a new file structure on it.
|
|
Volume set
|
Combination of several volumes; has the
appearance of one large volume.
|
Information on a disk or CD-ROM can be accessed as logical blocks on the disk or as virtual blocks of files on the disk.
Disk and CD-ROM File Structures ![]()
On-Disk
Structure (ODS) refers to a logical structure given
to information stored on a disk or CD-ROM. It is a hierarchical
organization of files, their data, and the directories needed to
gain access to them. The OpenVMS file system implements the On-Disk
Structure and provides access control to the files located on the
disk.
On-Disk Structure Hierarchy of a File shows the hierarchy of blocks, clusters, extents, and files in the On-Disk Structure. The number of blocks in any one extent is a multiple of the cluster size. The figure assumes a cluster size of 2 blocks.
|
Figure 1 On-Disk Structure Hierarchy of a File |
![]() |
OpenVMS File Structure Options![]()
On-Disk Structures include Levels 1, 2, and 5. (Levels 3 and 4 are internal names for ISO 9660 and High Sierra CD formats.) ODS-1 and ODS-2 structures have been available on OpenVMS systems for some time. Beginning with OpenVMS Version 7.2 on Alpha (and on I64) systems, you can specify ODS-5 to format disks as well.
The OpenVMS Alpha and I64 operating systems recognize all the file structures for disks and CD-ROMs shown in File Structure Options on OpenVMS Systems except ODS-1. On VAX systems, you can mount ODS-5-enabled volumes, but you cannot access ODS-5-specific features. You can use one or more formats to incorporate a volume and file structure that is compatible with the input/output processing used by the system.
When you create a file, you normally specify a file name to OpenVMS Record Management Services (RMS), which assigns this name to the file on an on-disk volume. RMS places the file name and file ID associated with the newly created file in a directory, which contains an entry defining the location for each file.
When you access a file, you supply the file name, which supplies a path to the file identifier through the directory entry. The file identifier, in turn, points to the location of the file header, which contains a listing of the extent or extents that locate the actual data.
Reserved Files on OpenVMS Systems![]()
Reserved files control the structure of a On-Disk Structure (ODS) Levels 2 and 5 volumes. (Only five of these files are used for a Level 1 volume.) Reserved Files identifies all reserved files, and indicates to which ODS level they pertain.
The files listed in Reserved Files are in the master file directory (MFD), [000000]. The HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems contains a description of each reserved file.
| Reserved File | File Name | Structure Level 13 | Structure Levels 2 and 5 |
|---|---|---|---|
|
Index file
|
INDEXF.SYS;1
|
X
|
X
|
|
Storage bit
map file
|
BITMAP.SYS;1
|
X
|
X
|
|
Bad block file
|
BADBLK.SYS;1
|
X
|
X
|
|
Master file
directory
|
000000.DIR;1
|
X
|
X
|
|
Core image
file
|
CORIMG.SYS;1
|
X
|
X
|
|
Volume set
list file
|
VOLSET.SYS;1
|
|
X
|
|
Continuation
file
|
CONTIN.SYS;1
|
|
X
|
|
Backup log
file
|
BACKUP.SYS;1
|
|
X
|
|
Pending bad
block
|
BADLOG.SYS;1
|
|
X
|
|
Volume security profile
|
SECURITY.SYS;1
|
|
X
|
Limits of Storage and Index File Bitmaps![]()
In previous versions of OpenVMS, both storage and index file bitmaps were limited to 255 blocks. This size, in turn, limited a volume to approximately one million allocation units, or clusters. Larger disks were required to have a larger cluster factor to accommodate the limit; for example, a 9 GB disk required a cluster factor of 18.
Beginning with OpenVMS Version 7.2, the limits of storage and index file bitmaps have been increased as follows:
| Type of Bitmap | Limit |
|---|---|
|
Storage bitmap
|
65535 blocks
|
|
Index file bitmap
|
4095 blocks
|
The increased bitmap limits have the following advantages:
The behaviors of the INITIALIZE and BACKUP commands reflect the larger bitmap sizes. Refer to the HP OpenVMS DCL Dictionary for INITIALIZE command details and the HP OpenVMS System Management Utilities Reference Manual: A--L for BACKUP utility details.
Message Displayed with Earlier Versions![]()
The following message is displayed on pre-Version 7.2 systems when you attempt to access a disk that was initialized on a Version 7.2 or later system:
%MOUNT-F-FILESTRUCT, unsupported file structure levelThe increased size of the BITMAP field is incompatible with earlier versions of OpenVMS.
Check the size of BITMAP.SYS on the disk you want to access. If the size is 256 or greater and you want to access the disk from a pre-Version 7.2 system, you must copy the data to a disk with a BITMAP.SYS that is less than 256 blocks. If you use the DCL command BACKUP/IMAGE, be sure to use the /NOINITIALIZE qualifier.
Comparison of ODS-1 (VAX only), ODS-2, and
ODS-5 (Alpha and I64) Formats ![]()
Comparison of ODS-1, ODS-2, and ODS-5 Formats compares specific characteristics
of On-Disk Structure (ODS) Levels 1, 2, and 5.
| Characteristic | ODS-1 (VAX only) | ODS-2 | ODS-5 (Alpha and I64) |
|---|---|---|---|
|
File name length
|
9.3
|
39.39
|
238 bytes, including the
dot and the file type. For Unicode, 236 bytes is 119 characters,
including the dot and the file type.
|
|
Character set
|
Uppercase alphanumeric
|
Uppercase alphanumeric
plus hyphen (-), dollar sign ($), and underscore (_)
|
ISO Latin-1, Unicode (refer
to the description in the OpenVMS User's Manual
.)
|
|
File versions
|
32,767 limit;
version limits are not supported
|
32,767 limit;
version limits are supported.
|
32,767 limit; version limits
are supported.
|
|
Directories
|
No hierarchies
of directories and subdirectories; directory entries are not ordered4
|
Alpha: 255
directory levels5
VAX: 8 directory levels (with rooted logical, 16) |
Alpha: 255 directory levels
VAX: 8 directory levels (with rooted logical, 16) |
|
System disk
|
Cannot be an
ODS-1 volume
|
Can be an ODS-2 volume
|
ODS-5 volume supported for Version
7.3-1 and higher
|
|
Page file,
swap file, dump file, parameter (.PAR) file, and other system files
|
Supported
|
Supported
|
Not supported
|
|
OpenVMS Cluster
access
|
Local access
only; files cannot be shared across a cluster
|
Files can be
shared across a cluster
|
Files can be shared across
a cluster. However, only computers running OpenVMS Version 7.2 or
later can mount ODS-5 disks. VAX computers running Version 7.2 or later
can see only files with ODS-2 style names.
|
|
Disk
|
Unprotected
objects
|
Protected objects
|
Protected objects
|
|
Disk quotas
|
Not supported
|
Supported
|
Supported
|
|
Multivolume
files and volume sets
|
Not supported
|
Supported
|
Supported
|
|
Placement control
|
Not supported
|
Supported
|
Supported
|
|
Caches
|
No caching
of file identification slots or extent entries
|
Caching of
file header blocks, file identification slots, and extent entries
|
Caching of file header blocks,
file identification slots, and extent entries
|
|
Clustered allocation
|
Not supported
|
Supported
|
Supported
|
|
Backup home block
|
Not supported
|
Supported
|
Supported
|
|
Protection
code E
|
E means "extend" for the
RSX-11M operating system but is ignored by OpenVMS
|
E means "execute access"
|
E means "execute
access"
|
|
Enhanced protection features
(for example, access control lists)
|
Not supported
|
Enhanced protection features
supported
|
Enhanced protection features supported
|
| Future enhancements to OpenVMS software will be based primarily on Structure Levels 2 and 5; therefore, Structure Level 1 volumes might be further restricted in the future. However, HP does not intend for ODS-5 to be the default OpenVMS file structure. The principal function of ODS-5 is to enable an OpenVMS system to be a server for other systems (such as Windows NT®) that have extended file names. |
The ISO 9660 Standard for CD-ROMs ![]()
The OpenVMS implementation
of On-Disk Structure conforms to the file structures defined by
the ISO 9660 standard.
ISO 9660 Terms defines
terms related to the ISO 9660 standard.
Two aspects of an implementation are required to support ISO 9660 file structures in an OpenVMS environment: partially recorded data blocks and data interleaving.
Extended
File Specifications on OpenVMS Alpha and I64
Systems ![]()
Extended
File Specifications allows files with Windows 95 style or Windows
NT style file names and attributes to reside on, and to be managed
from, OpenVMS Alpha or I64 systems. Extended File Specifications
support can also be selected on a per-volume basis.
Traditional and Extended File Names![]()
In an Extended File Specifications environment, you can select either of the following naming styles for file specifications:
For detailed definitions of traditional and extended file names as well as other introductory information about Extended File Specifications, refer to the OpenVMS User's Manual .
The following sections describe the current levels of disk, mixed-version, mixed-architecture, and network support for Extended File Specifications on OpenVMS systems.
System and User Disk Support ![]()
Restrictions
and suggestions for using Extended File Specifications on your system
are as follows:
Mixed-Version Support ![]()
Users on OpenVMS Version 7.2 and later systems can take advantage
of Extended File Specifications capabilities. In contrast, systems
running prior versions of OpenVMS cannot mount ODS-5 volumes or correctly
handle extended file names.
The following sections describe support on OpenVMS Version 7.2 and on prior versions of OpenVMS in a mixed-version cluster.
Users on OpenVMS Version 7.2 Systems![]()
Users on OpenVMS Version 7.2 systems can continue to access pre-Version 7.2 files and directories. For example, they can perform all of the following actions:
Users on Systems with Versions Prior to OpenVMS 7.2![]()
On mixed-version clusters, some restrictions exist. Users on a version of OpenVMS prior to Version 7.2 have these limitations:
Mixed-Architecture
Support ![]()
All Extended File Specifications capabilities are available
on OpenVMS Alpha and I64 systems. Nearly all the current ODS-2 disk
and file management functions remain the same on both VAX and Alpha
Version 7.2 systems; however, extended file naming and parsing are
not available on VAX systems.
The following sections describe support on OpenVMS VAX and Alpha or I64 systems in a mixed-architecture cluster.
Limited Extended File Specifications Capabilities on
VAX Systems![]()
In mixed-architecture OpenVMS Version 7.2 clusters, the following limited Extended File Specifications capabilities are available on OpenVMS VAX systems:
On an OpenVMS VAX system, users cannot successfully create or restore an ODS-5 image save set. However, these users can successfully restore ODS-2-compliant file names from an ODS-5 save set.
Users can also perform a disk-to-disk copy from ODS-5 to ODS-2 as long as they do not specify /IMAGE.
For more information, refer to the HP OpenVMS System Management Utilities Reference Manual: A--L.
Network
Support ![]()
For OpenVMS Version
7.2 and later, the length of a file specification that can be sent
over the network using DECnet is shorter than the maximum size of
a file specification without the use of a network.
Enabling
Extended File Specifications Features ![]()
To enable Extended File
Specifications On-Disk Structure features for a volume on an OpenVMS
Alpha or I64 system, you must perform one of the following actions:
| Task | Reference |
|---|---|
|
Initialize
a new volume as ODS-5
|
Initializing a New Volume with ODS-5 Format
|
|
Convert an existing volume
from ODS-2 to ODS-5
|
Converting from ODS-2 to ODS-5
|
Creating ODS-5 volumes allows you to take advantage of extended file names for HP Advanced Server for OpenVMS clients; you can see and manage these names from OpenVMS Alpha or I64 systems.
| Extended File Specifications are not available on systems running versions of OpenVMS Alpha prior to Version 7.2. On these systems, you cannot mount ODS-5 volumes nor take advantage of extended file names on an OpenVMS file system. |
Tape Concepts ![]()
The file storage
system for magnetic tapes is based on the standard magnetic tape
structure as defined by ISO 1001-1986, which is compatible with
several national standards such as ANSI X3.27-1987.
For more information about tape concepts, refer to the Guide to OpenVMS File Applications .
Terms Related to Magnetic Tapes defines terms that apply to magnetic tapes.
Record Blocking ![]()
Record Blocking shows how record
blocking can save space.
|
Figure 2 Record Blocking |
![]() |
Assume that a 1600-bits-per-inch magnetic tape contains 10 records that are not grouped into a block. Each record is 160 characters long (0.1 inch at 1600 bits per inch) with a 0.6-inch IRG after each record, which uses 7 inches of tape. However, placing the same 10 records into one block uses only 1.6 inches of tape (1 inch for the data records and 0.6 inch for the IRG).
Record blocking also increases the efficiency of the flow of data into the computer. For example, 10 unblocked records require 10 separate physical transfers, while 10 records placed in a single block require only one physical transfer. Moreover, a shorter length of magnetic tape is traversed for the same amount of data; thus, the operation is completed in less time.
However, record blocking requires more buffer space to be allocated for your program. The greater the number of records in a block, the greater the buffer size requirements. You must determine the point at which the benefits of record blocking cease. Base this determination on the configuration of your computer system and your environment.
Multiple Tape Densities (Alpha and I64) ![]()
In versions of OpenVMS Alpha prior to Version 7.2, the range of densities
that users were able to set for magnetic tape devices was limited.
On OpenVMS Version 7.2 and later Alpha systems and on I64 systems, that
range includes any density that a specific tape drive supports.
Because of this enhancement, exchanging tapes among tape drives
with different default settings for density is much easier.
You can set densities using the following DCL commands:
Refer to the HP OpenVMS DCL Dictionary for details about using the /DENSITY qualifier with these DCL commands.
You can also set densities using the following system management utilities:
Refer to the MOUNT command in the HP OpenVMS DCL Dictionary and to the BACKUP utility in the HP OpenVMS System Management Utilities Reference Manual for details about using the /DENSITY qualifier. Also refer to Using BACKUP for details about using the /DENSITY qualifier with BACKUP.
The command in this example initializes the media in the MKA500: drive to tk85 density with a label of TEST.$INITIALIZE/DENSITY=tk85 MKA500: TEST
The following densities are valid in the command strings for DCL commands and system management utilities: 800, 1600, 6250, DAT, 833, DDS1, DDS2, DDS3, DDS4, TK50, TK70, TK85, TK86, TK87, TK88, TK89, 8200, 8500, 3480, 3490E, AIC, AIT, and DEFAULT.
You cannot use multiple tape densities on one piece of media. In other words, one density applies to one piece of media. If you do not specify a density, the default density is used; the default is the highest density a particular drive supports.
Density changes can occur only at beginning-of-tape (BOT). Once media is initialized to a density, the media remains at that density until it is reinitialized to a different density.
If a density is not supported on a particular device, depending on the drive, the density field either remains the same or takes the default. If a drive does not support the density you select, the system displays an invalid density error. Some drives do not report the error and simply ignore your selection, leaving the media at the previous density.
When media is set to a specific density, the "density" field
displayed when you enter $ SHOW DEVICE/FULL MKA300:,
for example, displays the corresponding ASCII string for density.
Magtape JENSO3$MKA300:, device type TZ87, is online, file-oriented device, error
logging is enabled, controller supports compaction (compaction, disabled),
device supports fastskip.
Error count 0 Operations completed 0
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 2048
Density TK85 Format Normal-11
Volume status: no-unload on dismount, position lost, odd parity.
Public
and Private Disk Volumes ![]()
A volume is one or more units of storage media that you can
mount on a device. The volume is the largest logical unit of disk
file structure.
This section explains the concepts of public and private volumes.
Public Disk Volumes ![]()
A public volume is a file-structured
disk volume that can contain both private and public files. Public volumes
can be either of the following ones:
| Type of Volume | Description |
|---|---|
|
System
volumes
|
Available to all the users
on a system
|
|
Group volumes
|
Available to all the
users in a group
|
As long as file protections permit it, all users have access to public volumes and to the files on them.
One way to permit users to create and store files on a public volume is to create a default directory on the public volume for each authorized user. You control access to public files and volumes by the protection codes that you establish.
A user is free to create, write, and manipulate files on a public volume only under the following conditions:
The following sections contain guidelines for setting up and maintaining public files and volumes.
You must balance users' space needs with the system's available mass storage resources. These determinations depend, in part, on whether you have relatively small or large mass storage capability. A comparison of the two follows.
The most common arrangement is to have one public volume with system files and the directories of privileged users, and other public volumes dedicated to user directories, databases, and applications required by your site.
Whichever arrangement you select, plan each public volume and monitor disk performance once the system is running:
You can often move system files off the system disk and use search lists or logical names to access them. See HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems for more information.
In large configurations, you can place secondary paging and swapping files on other devices to balance disk load. See HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems for more information. The OpenVMS Performance Management provides detailed information about redistributing system files and achieving a balanced disk load.
Private Disk Volumes ![]()
A private volume is a file-structured
volume that contains only private files.
Under some circumstances, users might want to perform their work on a device that unauthorized users cannot access. By creating a private volume and mounting it on a device allocated exclusively to a user's process, you ensure that users can perform their work without fear of interference from others.
Users can often prepare and manipulate their own private volumes. They might, however, need your assistance if the computer and its peripheral devices are off limits to or remotely located from them. Users requiring assistance can use the operator communication manager (OPCOM) to communicate with an operator. See Assisting Users in Mounting Volumes for instructions on answering users' requests for assistance.
1 This usage of cluster does not refer to a set of nodes that form an OpenVMS Cluster environment; it refers only to disks.
2 A logical block resides at an absolute address on a disk; a virtual block, on the other hand, resides at an address relative to a file.
3 VAX specific
4 RSX-11M, RSX-11D, RSX-11M-PLUS, and IAS systems do not support subdirectories and alphabetical directory entries.
5 Prior to OpenVMS Version 7.2, RMS limited directory levels to 8 or 16, although PATHWORKS and other programs that did not use RMS could use unlimited directory depth.
( Number takes you back )
|
|
|