| Previous | Contents | Index |
The NFS protocol specification is defined in several RFCs:
The protocol provides for stateless operations where:
Stateless servers provide robustness when there are client, server, or
network failures. If a client fails, an NFS server need not take action
to continue normal operation. If a server or the network fails, NFS
clients continue to attempt completing NFS calls until the server or
network is fixed. This robustness can be important in a complex network
of heterogeneous systems that is not under the control of a single
network manager.
4.3 NFS Client and Server Software
NFS consists of the NFS server and the NFS client software. The NFS server is implemented as a daemon, waiting for requests from clients. The NFS server does not retain the state of the NFS client.
The NFS server daemon is multithreaded; it processes multiple NFS client calls, in parallel. The NFS server daemon is also an event-driven, asynchronous process. Each NFS client call contains all the information necessary to complete the request.
The NFS client software implements a state mechanism that maintains all information required for processing client requests. Each client operation can be requested more than once and contains all the information necessary to complete the request. This model presumes no file open and close requests because these require saving the state of the object and that the server write data to the disk before returning the reply message to the user.
When mounting a remote file system, an NFS client sends a message that
makes the remote file system part of the local file directory. The
remote host redirects operations that access files on the remote file
system to the NFS client software. The NFS client and NFS server then
exchange messages.
4.4 Related Databases
NFS servers and NFS clients use the proxy database to provide users access to remote file systems. The NFS server also uses the export database. The export database includes file system names.
All OpenVMS nodes running the NFS server software can share the proxy and export databases. Table 4-2 shows the databases used by the NFS server and NFS client.
| Entity | Database | File Name | Logical Name |
|---|---|---|---|
| Server | Export database | TCPIP$EXPORT.DAT | TCPIP$EXPORT |
| Server | Proxy database | TCPIP$PROXY.DAT | TCPIP$PROXY |
| Client | Proxy database | TCPIP$PROXY.DAT | TCPIP$PROXY |
The PC-NFS daemon (PC-NFSd) provides authentication and printing services for PCs.
The PC-NFS daemon provides the following functions required for printing:
NFS accommodates numerous key differences between UNIX and OpenVMS to make user interaction between the two operating systems appear transparent. These differences are discussed in the remainder of this chapter and include:
Table 4-3 lists differences between the OpenVMS and UNIX directory hierarchies.
| UNIX | OpenVMS |
|---|---|
| May reside on multiple volumes. | Resides on one volume having one root above all directories on the volume. |
| Devices not included in file specification. | Devices included in file specifications. |
Figure 4-1 shows a UNIX directory. The UNIX hierarchy appears as one tree that can be located on more than one device.
Figure 4-1 UNIX Directory Hierarchy
An OpenVMS file specification is limited to eight directory levels 1 and has the following format:
device:[directory.subdirectory] filename.type;version
The following delimiters separate the file specification components:
A UNIX file specification, called a pathname, has the following format:
/directory/directory/filename
The slash (/) is the only delimiter that the UNIX file specification format uses. The first slash in a UNIX file specification represents the root directory. Subsequent slashes separate each component in the file specification (the directories from the other directories and the file name). In theory, there is no limit to the number of directory levels in a UNIX file specification, whereas an OpenVMS file specification is limited to eight directory levels.
Absolute and Relative File Specifications
OpenVMS and UNIX both have two types of file specifications or pathnames: absolute pathname and relative pathname.
On UNIX systems, absolute pathnames use the entire directory path that leads to the file, beginning with the root, which is represented by an initial slash. The root directory is the first directory in the file system. All other files and directories trace their ancestry back to the root. Relative pathnames begin the directory path with the current working directory and exclude the current working directory name in the pathname. There is no initial slash in a relative name.
For example, using Figure 4-1, a UNIX absolute pathname would be /usr/jones/accounting/calc whereas the relative pathname for the file calc in the current directory /usr/jones is accounting/calc.
A UNIX pathname can have a maximum of 1024 characters; an OpenVMS file specification can have a maximum of 255 characters.
A complete OpenVMS file name specification includes the file name, the file type, and an optional version number, from left to right in that order. The file name and file type can each have up to 39 characters and are separated with a period (for example: FILE_NAME.TXT;1). The valid characters in a file name or type include: A--Z, 0--9, underscore (_), hyphen (--), and dollar sign ($). Version numbers (following a semicolon) are decimal numbers from 1 to 32767; they differentiate versions of the same file.
A UNIX file specification generally contains up to 1024 characters, with each element of the pathname containing up to 255 characters. Some older versions of the UNIX operating system limit the size of one element to 14 characters or have other limits that you can change if you recompile the kernel.
In theory, you can use any ASCII character in a UNIX pathname except for the slash (/) and null characters. For example, a file name of report.from.january_24 is valid. However, you should avoid using some characters (such as the pipe (|) character) because these characters can have special meaning to the UNIX shell.
The OpenVMS file system is not case sensitive. However, the UNIX operating system treats upper and lowercase characters as different characters.
For example, on a UNIX system the following file names represent three different files; however, on an OpenVMS system they represent one file.
File types are important in OpenVMS file name identification. The file type usually describes the kind of data in the file. For example, a text file typically has a file type of .TXT. Directories all have file types of .DIR;1.
Although UNIX systems do not use file types, UNIX does use certain naming conventions that resemble OpenVMS file types. For example, file names ending in .txt are text files. UNIX directories do not have special file types.
Every OpenVMS file has a version number. When a file is created, the system assigns it a version number of 1. Subsequently, when a file is edited or additional versions of that file are created, the version number automatically increases by 1. Therefore, many versions of a file with the same file name can exist in the same directory.
The UNIX file system does not support automatic creation of multiple
versions. In most cases, if you edit a UNIX file, the system saves only
the most recently edited copy.
4.6.3 Linking Files
A link is a directory entry that refers to a file or a directory. On UNIX systems, files cannot exist without links and a file can have multiple links. On an OpenVMS system, files can exist without any links.
There are two kinds of links: hard links and symbolic links.
A hard link to a file is indistinguishable from the original link established when the file was created. These additional links allow users to share the same file under different pathnames. A hard link cannot span file systems.
On UNIX systems, any changes to the file are independent of the link used to refer to the file. The UNIX system maintains a count of the number of links to each file. If removing a link results in the link count becoming zero, the file is deleted. A file cannot be deleted except by removing all of its links.
The OpenVMS system also allows you to perform a similar function with the SET FILE/ENTER and SET FILE/REMOVE commands. The OpenVMS operating system does not maintain a count of links to a file. As a result, you can delete a file, and not delete its links.
The UNIX operating system cannot distinguish the order in which links are created. Therefore, all links to a file are of equal value. |
A symbolic link is a type of file that contains the name of the file to which it is connected. Symbolic links provide a path to the original file.
A UNIX symbolic link can span file systems. Unlike the hard link, the symbolic link does not maintain a link count. Symbolic links can exist after the file has been deleted. However, an error is returned if the symbolic link file is accessed after the file it names is deleted.
OpenVMS file systems do not support symbolic links. |
The OpenVMS file system supports three file organizations: indexed, relative, and sequential. OpenVMS also supports the following record formats and record attributes:
The UNIX file system supports only byte streams. The records in UNIX text files have the same format as the OpenVMS Record Management Services (RMS) STREAM_LF record format.
A DIGITAL TCP/IP Services for OpenVMS NFS server dynamically converts sequential files that are not streams (STREAM_LF or STREAM_CR) when read by NFS clients.
NFS clients have read-only access to non-stream files. |
Data conversion to STREAM_LF format may change the size of a file because of differences in the record formatting overhead. Therefore, the product's NFS server does not know the correct size of a non-stream file until it has dynamically converted the file at least once.
For NFS client requests that require the file size to be returned, but
do not require reading the file (for example, ls
-l), the product's NFS server returns an estimate of the
size based on the unconverted size. The first time the server needs to
read the file, it computes the correct converted file size and caches
the information for future use.
4.6.5 File Ownership
The OpenVMS and UNIX operating systems use different mechanisms for file ownership.
The OpenVMS operating system controls file ownership and protection through a user identification code (UIC).
A UIC is a 32-bit value that consists of a 14-bit group number, a 16-bit member number, and 2 reserved bits. Each user of the system has a UIC defined in the SYSUAF file. Access to objects depends on the relationship between the UIC of the accessing process and the UIC of the object (the file or directory).
OpenVMS controls file access through an access control list (ACL). You can deny or grant read, write, execute, delete, and control access to a user or group of users who have the identifier specified by the ACL. For additional ACL information, refer to the OpenVMS documentation set.
Because the NFS protocol does not provide ACL support, the NFS client is not aware of an ACL applied to the file by the NFS server. Therefore, the NFS client cannot use an ACL to control file access. Only the NFS server can use an ACL when accessing files. Other access control is determined through standard file protections. Attempts to implement access control through NFS software cause ambiguity. Therefore, an ACL is only used to deny access to OpenVMS files.
The UNIX operating system controls access to files with user
identification (UID) and group identification (GID). Some versions of
UNIX use a 16-bit UID and GID; others may use different values. For
example, DIGITAL UNIX and NFS use 32-bit UIDs and GIDs.
4.6.6 File Protections
The OpenVMS and UNIX operating systems use similar file protection schemes as shown in Table 4-4.
| Mechanism | OpenVMS File System | UNIX File System |
|---|---|---|
| User classifications |
SYSTEM (S)
OWNER (O) GROUP (G) WORLD (W) Classification depends on the relationship between the UID of the accessing process and the object. |
user (u) --- The user has a matching UID
group (g) --- The group has a matching GID other (o) --- Any other user System category is not used; system administrators always have access to UNIX files. |
| Protection levels |
READ (R)
WRITE (W) EXECUTE (E) (controls file execution and directory search access) DELETE (D) |
read (r)
write (w) --- controls delete access; if a file has write protection enabled, you can delete it execute (x) --- controls file execution and directory search access |
| Syntax | s:rwed,o:rwed,g:rwed,w:rwed |
rwxrwxrwx
The protection levels are divided into groups of three characters, using the following format:
|
The DIGITAL TCP/IP Services for OpenVMS software allows you to create a logical UNIX style file system on an OpenVMS host. Remote UNIX hosts that have NFS software can then access this file system. When a remote UNIX system accesses files, these files conform to the UNIX file system rules, not OpenVMS rules. This ensures that existing UNIX applications will work without change. For information about creating a UNIX file system on an OpenVMS host, refer to the DIGITAL TCP/IP Services for OpenVMS Management guide.
An NFS server on a DIGITAL TCP/IP Services for OpenVMS host can support multiple logical UNIX style file systems. A logical UNIX style file system is organized as a tree with a single root node, non-leaf nodes being directory files, and leaf nodes being either directory or regular data files. The logical UNIX style file system resides on a Files-11 formatted disk and is represented as a set of Files-11 files called a container file system.
The UNIX style file names and attributes are catalogued in the container file, one of the files in the container file system. The container file also has a representation of the UNIX style directory hierarchy and a pointer to the data file for each file name. In addition to its UNIX style name, each file in the container file system has a valid Files-11 file name assigned by the system.
An OpenVMS directory exists for each UNIX directory stored in the container file. All files cataloged in a UNIX directory are also cataloged in the corresponding OpenVMS directory. However, the UNIX directory hierarchy is not duplicated in the OpenVMS directory hierarchy.
Each UNIX style file is represented as an OpenVMS data file. Therefore, OpenVMS utilities, such as BACKUP, can use standard methods to access these files.
1 The TCP/IP Services for Open VMS implementation of NFS currently only supports the ODS-2 On-Disk Structure. The eight directory level limitation is a limitation of ODS-2. |
| Previous | Next | Contents | Index |