File System Operation

Since Files-11 is used on systems with many concurrent users, it must be able to satisfy a variety of requests from a variety of sources. At any given time, some users may be creating files, others may be deleting files, and yet others may be extending existing files. These are operations that must be serialized, because they move disk blocks between the allocated and free states. Ordinary operations, such as reading files and writing to them (defined here as filling blocks which have already been allocated) may not need any serialization, so long as each open file has a maximum of one potential writer at once.

Note 

The activities listed here are concerned with data at the block level only. OpenVMS RMS, described later, has already performed any necessary record-level processing.

Processes request file system services through a construct known as an I/O channel. Each process has a fixed number of channels. A given channel holds context information, such as which device and/or file is accessed on it. When a process initiates an I/O operation, the process uses a system service called queue I/O request ($QIO) to which it supplies the channel on which to act, as well as a number of arguments describing the action to be carried out.

Note 

I/O channels are used with all types of devices, not just disks.

A particular part of the file system known as the extended $QIO processor (XQP) performs tasks that cannot be performed by the $QIO system service or by the device driver. Such tasks include intervening when there is not enough virtual-to-logical block mapping information in memory and operations that do not involve a data transfer, such as associating a file with an I/O channel. The XQP essentially replaces the older-style ancillary control process (ACP) approach. An ACP is a dedicated detached process that handles these operations for a certain class of device, and they are still used in certain circumstances. The XQP was developed, in part, because ACPs can become performance bottlenecks and the XQP code can be mapped into each process's P1 space, distributing the load.

To maintain the states of devices and files and the accesses to them, the file system maintains various control blocks linked together in lists. For example, a channel on which a file is accessed will have an associated window control block (WCB), which maintains mapping information (copied from retrieval pointers) for the file being accessed. This WCB will itself be associated with a file control block (FCB), which contains information about the file, including information about other accessors to that file.

As files are created, extended, deleted, read, and written, these control blocks are kept updated to reflect the current state of the file system. Attempts to perform unauthorized or inconsistent operations, such as writing to a read-only file or reading a file to which you are not allowed access, are rejected.

OpenVMS supports asynchronous I/O, wherein a process requests an I/O operation and then may perform other work while the I/O operation is in progress. When the I/O is complete, the process is notified, usually via an event flag (see "Process Scheduling" in Chapter 17, "The Process").



Getting Started with OpenVMS(c) A Guide for New Users
Getting Started with OpenVMS: A Guide for New Users (HP Technologies)
ISBN: 1555582796
EAN: 2147483647
Year: 2005
Pages: 215

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net