 |
 |
|
 |
 |
|
|
|
|
|
|
Encyclopedia :
F :
FI :
FIL :
Files-11 |
|
|
Files-11Files-11, also known as on-disk structure, is the filesystem used by Hewlett-Packard's OpenVMS operating system, and also (in a simpler form) by the older RSX-11. It is a hierarchical filesystem, with support for access control lists, record-oriented I/O, remote network access, and file versioning. Files-11 is similar to, but significantly more advanced than, the filesystems used in previous Digital Equipment Corporation operating systems such as TOPS-20 and RSTS/E. HistoryThe native OpenVMS filesystem is descended from older DEC operating systems, and is similar in many ways. One of the major differences, however, is the layout of directories. These filesystems all provided some form of rudimentary non-hierarchical directory structure, typically based on assigning one directory per user account. Under RSTS/E, each user account was represented by two numbers, a [project,programmer] pair, and had an associated directory. Special system files, such as program executables and the OS itself, were stored in the directory of a reserved system account. While this was suitable for PDP-11 systems, which possessed limited permanent storage capacity, the advent of VAX systems with very large hard drives (for the time) required a more flexible method of file storage—hierarchical directory layout in particular, the most notable improvement in ODS-2. Overview"Files-11" is the general term for five separate filesystems, known as on-disk structure (ODS) levels 1, through 5. Support for each filesystem is via individual ancillary control processes (ACPs), one per each of the ODS levels. ODS-1 is the flat filesystem used by the RSX-11 OS, supported on older VAX systems for RSX compatibility, but never used to support VMS itself; it has been largely superceded by ODS-2 and ODS-5. ODS-2 is the standard VMS filesystem, and remains the most common filesystem for system disks (the disk on which VMS itself is installed). Although seldom referred to by their ODS level designations, ODS-3 and ODS-4 are the Files-11 support for the CDROM ISO 9660 and High Sierra filesystems, respectively. ODS-5 is an extended version of ODS-2 available on Alpha and Itanium platforms which adds support for case-preserving filenames with non-ASCII characters and improvements to the hierarchical directory support. It was originally intended for file serving to Microsoft Windows or other non-VMS systems as part of the "NT affinity" project, but is also used on user disks and Internet servers. Directory layoutA typical Files-11 directory hierarchy. All files and directories in a Files-11 filesystem are contained inside one or more parent directories, and eventually under the root directory, the master file directory (see below). The filesystem is therefore organised in a tree-like structure. In this example (see right), File 2 has a directory entry under both Dir 2 and Dir 3; it is "in" both directories simultaneously. Even if deleted from one, it would still exist in the other directory until deleted from there also. Disk organization and namingAn operational VMS system has access to one or more online disks, each of which contains a complete, independent filesystem. These are either local storage or, in the case of a cluster, storage shared with remote systems.
Figure 1: Sample OpenVMS cluster disk configuration. In an OpenVMS cluster configuration, non-private disks are shared between all nodes in the cluster (see figure 1). In this configuration, the two system disks are accessible to both nodes via the network, but the private disk is not shared: it is mounted for use only by a particular user or process on that machine. Access to files across a cluster is managed by the OpenVMS Distributed Lock Manager, an integral part of the filesystem. Multiple disks can be combined to form a single large logical disk, or volume set. Disks can also be automatically replicated into shadow sets for data security or faster read performance. A disk is identified by either its physical name or (more often) by a user-defined logical name. For example, the boot device (system disk) may have the physical name $3$DKA100, but it is generally referred to by the logical name SYS$SYSDEVICE. Filesystems on each disk (with the exception of ODS-1) are hierarchical. The standard filename format consists of a nodename, a username and password, a device name, directory, filename, file type, and a version number, in the format: NODE"user pass"::device:[dir.subdir]filename.type;ver For example, [DIR1.DIR2]FILE.EXT refers to the latest version of FILE.EXT, on the current default disk, in directory [DIR1.DIR2]. DIR1 is a subdirectory of the master file directory (MFD), or root directory, and DIR2 is a subdirectory of DIR1. A disk's MFD is identified by [000000]. Any part of the filename can be omitted, in which case it will be taken from the current default file specification. The default file specification replaces the concept of "current directory" in other operating systems by providing a set of defaults for node, device name, directory and filename. All processes have a default file specification which includes disk name and directory, and most RMS filesystem routines accept a default file specification which can also include the file type; the TYPE command, for example, defaults to ".LIS" as the file type, so the command TYPE F, with no extention, will attempt to open the file F.LIS. Every file has a version, which is 1 at file creation, and is incremented every time a file is written to; old versions are only deleted when the file's version limit (as set by SET FILE/VERSION_LIMIT) is reached. Old versions are thus not overwritten, but are kept on disk and may be retrieved at any time. The architectural limit on version numbers is 32767. ODS-2 only supports eight levels of subdirectories, and only uppercase, alphanumeric filenames (plus the underscore, dash, and dollar sign) which are limited to 39 characters for the filename and another 39 for the extension. ODS-5 expands the character set to lowercase letters and most other printable ASCII characters, as well as ISO Latin-1 and Unicode characters, increases the maximum filename length and allows unlimited levels of subdirectories. When constructing a pathname for an ODS-5 file which uses characters not allowed under ODS-2, a special "^" syntax is used to preserve backwards compatibility; the file "file.tar.gz;1" on an ODS-5 disk, for example, would be referred to as "file^.tar.gz"—the file's name is "file.tar", and the extension is ".gz". File security: protection and ACLsVMS file security is defined by two mechanisms, UIC-based access control and ACL-based access control. UIC access control is based on the owner of the file and the UIC, or user, accessing the file. Access is determined by four groups of permissions:
UIC-based access control is also affected by four system privileges, which allow users holding them to override access controls: ACLs allow additional privileges to be assigned on a user– or group–specific basis; for example, a web server's UIC could be granted read access to all files in a particular directory. ACLs can be marked as inherited, where a directory file's ACL applies to all files underneath it. ACLs are modified using the EDIT/ACL command, and take the form of identifier/access pairs. For example, the ACL entry (IDENTIFIER=HTTP$SERVER,ACCESS=READ+EXECUTE)
would allow the user HTTP$SERVER to read and execute the file. Logical namesA logical name is an additional name given to a disk, or a name used to refer to a particular directory as if it were a disk. For example, the logical SYS$SYSDEVICE is assigned to the system's boot device at startup. A logical name normally refers to a single directory or disk, e.g. SYS$LOGIN: which is the user's login (home) directory (or directories); these logicals cannot be used as true disk names—SYS$LOGIN:[DIR]FILE is not a valid file specification. However, concealed logical names, defined by DEFINE/TRANSLATION=CONCEALED, can be used in that way; these are defined with a trailing "." on the directory specification: $ DEFINE/TRANS=CONCEAL HOME DISK$USERS:[username.]
would allow HOME:[DIR]FILE to be used. Record-oriented I/O: Record Management ServicesRecord Management Services is the structured I/O layer of the VMS operating system. RMS provides comprehensive program support for managing structured filess, such as record-based and indexed database files. The VMS filesystem, in conjunction with RMS, extends files access past simple byte-streams and allows OS-level support for a variety of rich files types. Each file in the VMS filesystem may be thought of as a database, containing a series of records, each of which has one of more individual fields. A text file, for example, is a list of records (lines) separated by a newline character. There are four record formats defined by RMS:
Physical layout: the On-Disk StructureAt the disk level, ODS represents the filesystem as an array of blocks, a block being 512 bytes, spanning one or more physical disks (volumes). Groups of blocks are organised into clusters. Each file on the volume is spread across one or more contiguous allocated clusters, called extents. Ideally, each file will have only one extent, but fragmentation issues and growth of files result in additional extents being allocated for single files. Every file on a Files-11 disk structure has a unique file identification (FID), composed of three numbers: the file number (NUM), the file sequence number (SEQ), and the relative volume number (RVN). The NUM and SEQ combined indicate where in the INDEXF.SYS file (see below) the metadata for the file is located; the RVN indicates the volume number on which the file is stored when using multi-volume file systems. DirectoriesThe structural support of an ODS volume is provided by the directory file—a special file containing a list of file names and their associated FIDs. At the root of the directory structure is the master file directory (MFD), the root directory which contains (directly or indirectly) every file on the volume.
'\'This diagram shows an example directory containing 3 files, and the way each filename is mapped to the INDEXF.SYS entry (each INDEXF entry contains more information; only the first few items are shown here).'' The Master File DirectoryAt the top level of an ODS filesystem is the master file directory (MFD), which contains all top-level directory files (including itself), and several system files used to store filesystem information. On ODS-1 volumes, a two-level directory structure is used: each user identifiation code (UIC) has an associated user file directory (UFD), of the form [GROUP.USER]. On ODS-2 and later volumes, the layout of directories under the MFD is free-form, subject to a limit on the nesting of directories (8 levels on ODS-2 and unlimited on ODS-5). On multi-volume sets, the MFD is always stored on the first volume, and contains the subdirectories of all volumes. The following system files are present in the ODS MFD:
After the boot block is the home block. This contains the volume name, the location of the location of the extents comprising the remainder of the index file, the volume owner's UIC, and the volume protection information. There are normally several copies of the home block, to allow recovery of the volume if it is lost or damaged. The rest of the index file is composed of file headers, which describe the extents allocated to the files residing on the volume, and file metadata such as the owner UIC, ACLs and protection information. Each file is described by one or more file headers—more than one can be required when a file has a large number of extents. The file header is a fixed-length block, but contains both fixed– and variable–length sections:
Layout of the INDEXF.SYS header. The file header begins with 4 offsets (IDOFFSET, MPOFFSET, ACOFFSET and ROFFSET). Since the size of the areas after the fixed-length header may vary (such as the map and ACL areas), the offsets are required to locate these additional areas. Each offset is the number of 16-bit words from the beginning of the file header to the beginning of that area. If the file requires multiple headers, the extension segment number (SEGNUM) contains the sequence number of this header, beginning at 0. STRUCLEV contains the current structure level (in the high byte) and version (in the low byte) of the filesystem; ODS-2 being strucure level 2. An increase in the version number indicates a backwards-compatible change that older software may ignore; changes in the structure level itself are incompatible. W_FID (containing three values: FID_NUM, FID_SEQ and FID_RVN, corresponding to the file, sequence, and relative volume number) contains the ID of this file; EXT_FID (again composed of three values) holds the location of the next extension header, if any. In both of these values, the RVN is specified as 0 to represent the "current" volume (0 is not normally a valid RVN). FILECHAR contains several flags which affect how the file is handled or organised: ACCMODE describes the privilege level at which a process must be running in order to access the file. VMS defines four privilege levels: user, supervisor, exec, and kernel. Each type of access - read, write, execute and delete - is encoded as a 2-bit integer. FILEPROT contains the discretionary access control information for the file. It is divided into 4 groups of 4 bits each: system, owner, group and world. Bit 0 corresponds to read access, 1 to write, 2 to execute and 3 to delete. Setting a bit denies a particular access to a group; clearing it allows it. If the file header is an extension header, BACKLINK contains the file ID of the primary header; otherwise, it contains the file ID of the directory file containing the primary entry for the file. Other files
|
|
|
This article is from Wikipedia. All text is available under the terms of the GNU Free Documentation License. |
|
| © 2008 Chamas Enterprises Inc. |
