Document revision date: 15 July 2002

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:

• Blocks
• Clusters
• Extents
• Files
• Volumes
• Volume Sets

Figure 1-1 Files--11 On-Disk Structure Hierarchy

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.

RMS allocates disk space for new files or extended files using multiblock units called clusters. The system manager specifies the number of blocks in a cluster as part of volume initialization.

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 allocation request.

1.2.2 Files--11 Control Files

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.

Table 1-5 Files--11 Control Files

Reserved File	File Name	Structure	Structure
		Level 1	Level 2
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
Security profile	SECURITY.SYS		X

All the files listed in Table 1-5 are listed in the master file directory (MFD), [000000].

1.2.2.1 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:

• Bootstrap block --- The volume's bootstrap block is virtual block number 1 of the index file. If the volume is a system volume, this block contains a bootstrap program that loads the operating system into memory. If the volume is not a system volume, this block contains a program that displays the message that the volume is not the system device but a device that contains user files only.
• Home block --- The home block provides specific information about the volume, including default file values. The following information is included within the home block:
  • The volume name
  • Information to locate the remainder of the index file
  • The maximum number of files that can be present on the volume at any given time
  • The user identification code (UIC) of the volume owner
  • Volume protection information (specifies which users can read and/or write the entire volume)
  The home block identifies the disk as a Files--11 ODS volume. Initially, the home block is the second block on the volume. Files--11 ODS volumes contain several copies of the home block to ensure that accidental destruction of this information does not affect the ability to locate other files on the volume. If the current home block becomes corrupted, the system selects an alternate home block.
• Alternate home block --- The alternate home block is a copy of the home block. It permits the volume to be used even if the primary home block is destroyed.
• Alternate index file header --- The alternate index file header permits recovery of data on the volume if the primary index file header becomes damaged.
• Index file bit map --- The index file bit map controls the allocation of file headers and thus the number of files on the volume. The bit map contains a bit for each file header allowed on the volume. If the value of a bit for a given file header is 0, a file can be created with this file header. If the value is 1, the file header is already in use.
• File headers --- The largest part of the index file is made up of file headers. Each file on the volume has a file header, which describes such properties of the file as file ownership, creation date, and time. Each file header also contains a list of the extents that define the physical location of the file. When a file has many extents, it may be necessary to have multiple file headers for locating them. When this occurs, each header is assigned a file identifier number to associate it with the appropriate file.
  When you create a file, you normally specify a name that RMS assigns to the file on a Files--11 ODS volume. RMS places the file name and file identifier associated with the newly created file in a directory that contains an entry defining the location for each file. To subsequently access the file, you specify its name. The system uses the name to define a path through the directory entry to the file identifier. In turn, the file identifier points to the file header that lists the file's extents.

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.

1.2.2.3 Bad Block File

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.

1.2.2.4 Master File Directory

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.

1.2.2.5 Core Image File

The core image file is listed in the MFD as CORIMG.SYS;1. It is not supported by the operating system.

1.2.2.6 Volume Set List File

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.

1.2.2.7 Continuation File

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.

1.2.2.8 Backup Log File

The backup log file is listed in the MFD as BACKUP.SYS;1. This file is reserved for future use.

1.2.2.9 Pending Bad Block Log File

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.

1.2.2.10 Security Profiles File (VAX Only)

This file contains the volume security profile and is managed with the SET/SHOW security commands.

1.2.3 Files--11 On--Disk Structure Level 1 Versus Structure Level 2

For reasons of performance and reliability, Files--11 On--Disk structure level 2, a compatible superset of structure level 1, is the preferred disk structure on an OpenVMS system.

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:

• Directories --- No hierarchies of directories and subdirectories, and no ordering of directory entries (that is, the file names) in any way. RSX--11M, RSX--11D, RSX--11M--PLUS, and IAS systems do not support subdirectories and alphabetical directory entries.
• Disk quotas --- Not supported.
• Multivolume files and volume sets --- Not supported.
• Placement control --- Not supported.
• Caches --- No caching of file header blocks, file identification slots, or extent entries.
• System disk --- Cannot be a structure level 1 volume.
• OpenVMS Cluster access --- Local access only; cannot be shared across an OpenVMS Cluster.

  Note In this document, discussions that refer to OpenVMS Cluster environments apply to both VAXcluster systems that include only VAX nodes and OpenVMS Cluster systems that include at least one Alpha node unless indicated otherwise.

• Clustered allocation --- Not supported.
• Backup home block --- Not supported.
• Protection code E --- Means extend for the RSX--11M operating system but is ignored by OpenVMS systems.
• File versions --- Limited to 32,767; version limits are not supported.
• Enhanced protection features (for example, access control lists) --- not supported.
• Extended File Specifications--- Not supported.
• RMS journaling for OpenVMS --- Not supported.
• RMS execution statistics monitoring --- Not supported.

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.

Another physical disk structure is called a cylinder. A cylinder consists of all tracks at the same radius on all recording surfaces of a disk.

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.

1.2.5 CD-ROM Concepts

CD-ROMs provide the following advantages when used to store data:

• Direct access of data allowed.
• Typically less expensive than other direct-access media.
• Large storage capability. Currently, you can store approximately 650 megabytes (1.27 million blocks) of data on a CD-ROM.
• Easier to store and handle off line.

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:

• Files--11 ODS-2---OpenVMS On Disk Structure, Level 2
• ISO 9660---A volume and file structure standard for information interchange on CD-ROMs
• High Sierra---Working paper of the CD-ROM Advisory Committee

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.² 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.

1.2.5.3 Files--11 C/D---ACPs

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:

• The ISO 9660 requirement for handling blocks that exceed 512 bytes
• Partial extents
• Interleaved data
• Undefined record formats

Logical Blocks Greater Than 512 Bytes

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.

Partial Data Blocks

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

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.

Undefined Record Format

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.

	privacy and legal statement
4506PRO_001.HTML