HP OpenVMS Systems Documentation
Guide to OpenVMS File Applications
1.2.1 Files--11 On-Disk Structure Concepts
The term Files--11 On-Disk Structure, or simply ODS, refers to the logical structure given to magnetic disks; namely, a hierarchical organization of files, their data, and the directories needed to gain access to them. The file system implements Files--11 ODS-1 (on VAX systems only) and Files--11 ODS-2 (on VAX and Alpha systems) to define the disk structure and to provide access to the files located on magnetic disks.
This section describes the Files--11 ODS levels and defines related terminology.
See Section 1.2.5 for information about concepts and logical structures used with CD-ROMs formatted in accordance with ISO 9660.
The primary difference between Files--11 ODS-1 and Files--11 ODS-2 is that Files--11 ODS-2 incorporates control capabilities that permit added features including volume sets (described later).
The logical ordering of ODS structures is listed below in order of ascending hierarchy:
Figure 1-1 Files--11 On-Disk Structure Hierarchy
The next higher level of Files--11 ODS is the volume (not illustrated), which is the ordered set of blocks that comprise a disk. However, a volume may include several disks that together make up a structure called a volume set. Because a volume set consists of two or more related volumes, the system treats it as a single volume.
The smallest addressable logical structure on a Files--11 ODS disk is a block, comprising 512, 8-bit bytes. During input/output operations, one or more blocks may be transferred as a single unit between a Files--11 ODS disk and memory.
Clusters may or may not be contiguous (share a common boundary) on a disk. Cluster sizes may range from 1 to 65,535 blocks. Generally, a system manager assigns a small cluster size to a disk with a relatively small number of blocks. Relatively larger disks are assigned a larger cluster size to minimize the overhead for disk space allocation.
An extent is one or more adjacent clusters allocated to a file or to a portion of a file. If enough contiguous disk space is available, the entire file is allocated as a single extent. Conversely, if there is not enough contiguous disk space, the file is allocated using several extents, which may be scattered physically on the disk. Figure 1-2 shows how a single file (File A) may be stored as a single extent or as multiple extents.
Figure 1-2 Single and Multiple File Extents
With RMS, you can exercise varying degrees of control over file space allocation. At one extreme, you can specify the number of blocks to be allocated and their precise location on the volume. At the other extreme, you can allow RMS to handle all disk space allocation automatically. As a compromise, you might specify the size of the initial space allocation and have RMS determine the amount of space allocated each time the file is extended. You can also specify that unused space at the end of the file is to be deallocated from the file, making that space available to other files on the volume.
When you need a large amount of file storage space, you can combine
several Files--11 ODS volumes into a volume set with file
extents located on different volumes in the set. You need not specify a
particular volume in the set to locate or create a file, but you may
improve performance if you explicitly specify a volume for a particular
Ten files control the structure of a Files--11 On--Disk Structure Level 2 volume. Only five of these files are used for a Files--11 On--Disk Structure Level 1 volume. Table 1-5 identifies all nine files, which are referred to as reserved files, and indicates to which Files--11 On--Disk Structure level they pertain.
126.96.36.199 Index File
Every Files--11 volume has an index file, which is created when the volume is initialized. This index file identifies the volume to the operating system as a Files--11 structure and contains the access data for all files on the volume. The index file, which is listed in the master file directory as INDEXF.SYS;1, contains the following information:
188.8.131.52 Storage Bit Map File
The storage bit map file controls the available space on a volume; this
file is listed in the master file directory as BITMAP.SYS;1. It
contains a storage control block, which consists of summary information
intended to optimize the Files--11 space allocation, and the bit map
itself, which lists the availability of individual blocks.
The bad block file, which is listed in the master file directory as
BADBLK.SYS;1, contains all the bad blocks on the volume. The system
detects bad disk blocks dynamically and prevents their reuse once the
files to which they are allocated have been deleted.
The master file directory (MFD) itself is listed in the MFD as 000000.DIR;1. The MFD, which is the root of the volume's directory structure, lists the reserved files that control the volume structure and may list both users' files and users' file directories. Usually the MFD is used to list the reserved files and users' file directories; users seldom enter files in the MFD, even on private volumes. In fact, on a private volume, it is most convenient for a user to create a directory that has the same name as the user's default directory on a system disk.
When the Backup utility (BACKUP) creates sequential disk save sets, it stores the save set file in the MFD.
For an explanation of user file directories and file specifications,
see the OpenVMS User's Manual.
The core image file is listed in the MFD as CORIMG.SYS;1. It is not
supported by the operating system.
The volume set list file is listed in the MFD as VOLSET.SYS;1. This
file is used only on relative volume 1 of a volume set. The file
contains a list of the labels of all the volumes in the set and the
name of the volume set.
The continuation file is listed in the MFD as CONTIN.SYS;1. This file
is used as the extension file identifier when a file crosses from one
volume to another volume of a loosely coupled volume set. This file is
used for all but the first volume of a sequential disk save set.
The backup log file is listed in the MFD as BACKUP.SYS;1. This file is
reserved for future use.
The pending bad block log file is listed in the MFD as BADLOG.SYS;1.
This file contains a list of suspected bad blocks on the volume that
are not listed in the bad block file.
This file contains the volume security profile and is managed with the
SET/SHOW security commands.
At volume initialization time (see the INITIALIZE command in the OpenVMS DCL Dictionary), structure level 2 is the default.
On VAX systems, structure level 1 should be specified only for volumes that must be transportable to RSX--11M, RSX--11D, RSX--11M--PLUS, and IAS systems, as these systems support only that structure level. Additionally, you may be required to handle structure level 1 volumes transported to OpenVMS systems from one of the previously mentioned systems.
Structure level 1 volumes have the following limitations:
1.2.4 Physical Structures
For performance reasons, you should be aware of certain physical aspects of a disk.
A disk (or volume) consists of one or more platters that spin at very high, constant speeds and usually contain data on both surfaces (upper and lower). A disk pack is made up of two or more platters having a common center.
Data is located at different distances from the center of the platter and is stored or retrieved using read/write heads that move to access data at various radii from the platter's center. The time required to position the read/write heads over the selected radius (referred to as a track) is called seek time. Each track is divided into 512-byte structures called sectors. The time required to bring the selected sector (logical block) under the read/write heads at the selected radius (track) is called the rotational latency. Because seek time usually exceeds the rotational latency by a factor of 2 to 4, related blocks (sectors) should be located at or near the same track to obtain the best performance when transferring data between the disk and RMS-maintained buffers in memory. Typically, related blocks of data might include the contents of a file or several files that are accessed together by a performance-critical application.
Figure 1-3 illustrates the relationship between tracks and cylinders.
Figure 1-3 Tracks and Cylinders
Because all blocks in a cylinder can be accessed without moving the disk's read and write heads, it is generally advantageous to keep related blocks in the same cylinder. For this reason, when choosing a cluster size for a large-capacity disk, a system manager should consider one that divides evenly into the cylinder size.
CD-ROMs provide the following advantages when used to store data:
184.108.40.206 CD-ROM On-Disc Formats
CD-ROM media may be formatted according to one or more media formats to incorporate a volume and file structure that is compatible with OpenVMS file system processing. OpenVMS supports CD-ROM access based on the following media formats:
220.127.116.11 Volume Structure
CD-ROM media is divided into logical sectors that are assigned a unique logical sector number. Logical sectors are the smallest addressable units of a CD-ROM. Each logical sector consists of one or more consecutively ascending physical sectors as defined by the relevant recording standard.2 Logical sectors are numbered in ascending order. The value 0 is assigned to the logical sector with the lowest physical address containing recorded data. Each logical sector includes a data field made up of at least 2048 bytes---but, in all cases, the number must be a power of 2.
ISO 9660-formatted CD-ROM volumes include a system area and a data area. The reserved system area includes logical sectors 0 through 15. The data area includes the remaining logical sectors and is called volume space. Volume space is organized into logical blocks that are numbered in consecutively ascending logical block number order.
Logical blocks are made up of at least 512 bytes---but, in all cases, the number of bytes must be a power of 2. However, no logical block can be larger than a logical sector.
The data area may include one or more Volume Descriptors,
File Descriptors, Directory Descriptors, and Path
Tables. These entities collectively describe the volume and file
structure of an ISO 9660-formatted CD-ROM. The
Ancillary Control Process (ACP) that manages I/O access to the
CD-ROM views the volume and file structure as an
integral part of the base OpenVMS file system.
The Files--11 C/D implementations allow OpenVMS systems to conform to the ISO 9660 standard at implementation level 2 and interchange level 3. This section describes how Files--11 C/D resolves incompatibilities between the OpenVMS file system and the ISO 9660 standard. The incompatibilities include the following:
OpenVMS device drivers are designed to handle files made up of 512-byte blocks that are uniquely addressable. The ISO 9660 standard supports logical blocks that are greater than 512-bytes. The Files-11 C/D ACP solves this incompatibility by converting ISO 9660 logical-block-size requests into OpenVMS-block-size requests at the file system level.
Any logical block in an ISO 9660 file extent may be partially filled with data. RMS assumes that all file blocks are filled with data, with the possible exception of the final block. When RMS finds a data block that is not filled, it attempts to start end-of-file processing. To prevent RMS from misinterpreting a partially-filled block as the final file block, the Files-11 C/D ACP uses I/O operations that combine adjacent ISO 9660 logical blocks into full 512-byte logical blocks.
Interleaving is used to gain efficiency in accessing information by storing sequential information on separate tracks. The OpenVMS file system is not natively compatible with interleaving, but ISO 9660 file extents may be interleaved. That is, ISO 9660 extents may consist of logical block groupings that are separated by interleaving gaps. In order to make the OpenVMS file system compatible with interleaving, the Files--11 C/D ACP treats each of the interleaved logical block groups as an extent.
ISO 9660 CD-ROMs may be mastered without a specified record format because the ISO 9660 media can be mastered from platforms that do not support the semantics of files containing predefined record formats. See the OpenVMS System Manager's Manual for details about mounting media with undefined record formats.