MultiNet 5.4 and later incorporates Version 3 of the NFS Server. Version 3 provides:
- support for 64-bit file sizes and offsets, to handle files larger than 2 gigabytes
- support for asynchronous writes on the server, to improve write performance
- additional file attributes in many replies, to avoid the need to re-fetch them, thus reducing network traffic
- a READDIRPLUS operation, to get file handles and attributes along with file names when scanning a directory
Just like the existing Version 2 NFS Server, the v3 Server provides several features that maintain the integrity of the OpenVMS filesystem.
First, the Server requires that the local system must register any user trying to access OpenVMS files. You do this through the PROXY database when you configure the Server and through later modifications as needed.
Second, you must export an OpenVMS directory for an NFS user to access it. The Server does this through the EXPORT database when you configure the Server and through later modifications as needed.
The initial offering of the NFS v3 Server utilizes a compiled binary format for it’s PROXY and EXPORT databases. Initially, these databases will use the existing proxy and export information found in the MultiNet NFS.CONFIGURATION file. To get the data into the proper format for the NFS v3 server, the CONVERT_NFS tool must be invoked. The CONVERT_NFS tool will read the NFS.CONFIGURATION file and set up the v3 only NFS_EXPORT.DAT and NFS_PROXY.DAT files. The CONVERT_NFS tool is invoked from the command line:
$ RUN CONVERT_NFS
There is minimal output, and two files are created - NFS_EXPORT.DAT and NFS_PROXY.DAT. At this time, any changes made via $ MULTINET CONFIGURE /NFS will not be picked up by the NFS v3 server until CONVERT_NFS is invoked. Future versions of MultiNet will streamline this process.
Refer to the MultiNet NFS V2 Server documentation in the previous chapter for further details on configuring proxies, exports, and the supporting protocols (i.e., portmapper, etc.) The NFS v3 Server utilizes the same supporting RPC protocols as the NFS v2 Server
NOTE: The initial implementation of the NFSV3 service (NFSV3_SERVER) will run in conjunction with the NFS service (NFS_SERVER) or by itself. The only dependency is the RPCPORTMAP service. A future version of MultiNet will incorporate an NFS server that supports both NFS v2 and NFS v3 from the same process.
NFS v3 clients access OpenVMS files on the NFS server by mounting directories. The MOUNT v3 protocol services the mount requests from clients attempting to mount an NFS v3 export.
Mounting procedures vary by client and may require superuser privileges, or in the case of PC clients, a username and password. Some clients mount a remote directory automatically when they reboot the system (as in the case of fstab). Others mount a remote directory dynamically when they reference the remote file (as with an automount).
Mount procedures require the following information:
• The pathname of the exported directory that matches the pathname in the EXPORT database
• The name of the host running the server that contains the files you want mounted
• A pathname on the client designated as the mount point
Example 28-1 shows a mount command provided by a Unix Solaris 5.9 Client to the NFSV3_SERVER running on host IRIS, using the defined export of NFS0:[USER.MNT] . The export is mounted onto the local /mnt partition.
Example 28-1 Client Mount Command
# mount IRIS:DKA0:\[USERS.MNT\] /mnt
In the example, IRIS is the name of the MultiNet host. DKA0:[USERS.MNT] is the exported directory. /mnt is the mount point on the Solaris client host.
Check your NFS client documentation before mounting directories.
The NFS protocol does not define standard file and record formats or a way of representing different types, such as text or data files. Each operating system can have a unique file structure and record format.
The Server provides access to all OpenVMS files. However, even though an NFS client can access a file, the client may not be able to correctly interpret the contents of a file because of the differences in record formats.
The UNIX operating system stores a file as a stream of bytes and uses a line feed (LF) character to mark the end of a text file line. PC systems also store a file as a stream of bytes, but use a carriage-return/line-feed (CRLF) character sequence to mark the end of a text file line. PC systems sometimes also use a Ctrl/Z character to mark the end of a file.
The OpenVMS operating system, with its Record Management Services (RMS), provides many file organizations and record formats. RMS supports sequential, relative, and indexed file organizations. It also supports FIXED, STREAM, STREAM_CR, STREAM_LF, UNDEFINED, VARIABLE, and variable with fixed size control area (VFC) files.
NFS clients most commonly need to share text files. STREAM is the RMS record format that most closely matches PC text files. STREAM_LF is the RMS record format that most closely matches UNIX text files.
In OpenVMS, you can store standard text files in VARIABLE, STREAM_LF, or VFC record format. Most OpenVMS utilities can process these text files regardless of the record format because the utilities access them through RMS.
The intent of the Server is to provide convenient access to the majority of OpenVMS files. Because many OpenVMS text files are VARIABLE or VFC format, the Server converts these files to STREAM or STREAM_LF format as it reads them.
The Server reads all files (except VARIABLE and VFC) block by block without interpreting or converting them. It reads VARIABLE and VFC files by converting them to STREAM or STREAM_LF, based on a selected option. The file on the NFS server remains unchanged.
The Server's automatic file conversion process can cause a slow reading of VARIABLE and VFC files. For example, in returning the file size, it reads the entire file. Full directory listings can also be slow if the directory contains a number of VARIABLE or VFC record format files. If you need frequent access to these files, consider converting them using the OpenVMS CONVERT utilities.
By default, the Server creates STREAM_LF files, but can also create STREAM files on demand. It writes all files except VARIABLE and VFC block by block without interpreting or converting them. If an NFS client tries to write to or change the size of an existing file not having STREAM, STREAM_LF, STREAM_CR, FIXED, or UNDEFINED format, the Server returns an EINVAL error.
This section describes the Server restrictions and implementation of the Network File System (NFS) protocol. The material presented here requires a thorough understanding of the protocols. It does not explain or describe the protocols.
The Server has the following OpenVMS-related restrictions:
• The Server supports Files-11 ODS-2 structure level disks, ODS-5 formatted disks, and any CD-ROM format.
• The Server does not implement volume protection. All exported devices should be public devices.
• The Server does not generate security or audit alarms. However, the Server writes access violations to log file MULTINET:NFSV3_SERVER.LOG.
• When creating files and directories, the Server sets the owner UIC of the file or directory to the UIC derived from the UID/GID in the create request authentication information or to the UID/GID in the set attributes information (if available).
The Server implements the following NFS protocol (version 3) procedures (while continuing to support version 2):
|
Procedures |
Description |
|
ACCESS (v3 only) (access) |
The server determines the access rights that a user, as identified by the credentials in the request, has with respect to a file system object. |
|
COMMIT CACHED WRITE DATA (v3 only) (commit) |
The server forces data to stable storage that was previously written with an asynchronous write call. |
|
CREATE FILE (create) |
The server creates files using the record format specified in the EXPORT database entry. The client may specify one of 3 methods to create the file: UNCHECKED: File is created without checking for the existence of a duplicate file. GUARDED: Checks for the presence of a duplicate and fails the request if a duplicate exists. EXCLUSIVE: Follows exclusive creation semantics, using a verifier to ensure exclusive creation of the target. |
|
GET ATTRIBUTES (getattr) |
Gets a file's attributes. The Server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: File protectionThe Server maps the OpenVMS file protection mask to the UNIX file protection mask. Number of linksAlthough OpenVMS supports hard links, it does not maintain a reference count. Therefore, the Server sets this value to 1 for regular files and 2 for directory files. UID/GIDThe Server maps a file owner's UIC to a UID/GID pair through the PROXY database. Device numberThe Server returns the device number as -1. Bytes usedThe total number of bytes used by the file. Filesystem idThe Server returns the filesystem ID as 0. Access, modify, status change timesThe OpenVMS system does not maintain the same file times as NFS requires. The Server returns the OpenVMS revision (modify) time for all three NFS times. For directory files, the Server returns the access, status change, and modify times as a reasonably recent time, based on the time of the last Server-initiated directory change, and the NFS_DIRTIME_TIMER parameter. This is a benefit to clients that cache directory entries based on the directory times. OpenVMS bases its time on local time, while UNIX bases its time on Universal time (or Greenwich mean time), and these times may not agree. The offset from Universal time specified when configuring MultiNet resolves the difference between local and Universal time. |
|
GET DYNAMIC FILESYSTEM INFO (v3 only) (fsstat) |
The server provides volatile information about a filesystem, including: – total size and free space (in bytes) – total number of files and free slots – estimate of time between file system modifications |
|
GET FILESYSTEM STATISTICS (v2 only) (statfs) |
Returns filesystem statistics. The Server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: Block sizeThe block size is 1024. Total number of blocksThe total number of blocks is the SYS$GETDVI MAXBLOCK parameter divided by 2. Blocks freeThe number of blocks free is the SYS$GETDVI FREEBLOCK parameter divided by 2. Blocks availableThe number of blocks available to unprivileged users is the same as the number of blocks free. |
|
GET STATIC FILESYSTEM INFO (v3 only)(fsinfo) |
The server provides nonvolatile information about a filesystem, including: – preferred and maximum read transfer sizes – preferred and maximum write transfer sizes – flags for support of hard links and symbolic links – preferred transfer size of readdir replies – server time granularity – whether or not times can be set in a setattr request |
|
LINK (link) |
Creates a hard link to a file. The Server stores the link count in an application access control entry (ACE) on the file. |
|
LOOKUP FILE (lookup) |
Looks up a file name. If the file name does not have a file extension, the Server first searches for a directory with the specified name. If the Server fails to locate a directory, it searches for the file name without an extension. |
|
MAKE DIRECTORY (mkdir) |
Creates a directory. The OpenVMS system does not allow the remote host to create more than eight directory levels from the root of the OpenVMS filesystem. The Server ignores access and modifies times in the request. |
|
READ DIRECTORY (readdir) |
Reads a directory. The Server returns file names using the filename mapping scheme as specified in the EXPORT database entry. The Server also drops the VMS version number from the file name for the highest version of the file. |
|
READ DIRECTORY PLUS ATTRIBUTES (v3 only) (readdirplus) |
In addition to file names, the server returns file handles and attributes in an extended directory list. |
|
READ FROM FILE (read) |
Reads from a file. The Server converts VARIABLE and VFC files to STREAM or STREAM_LF format (depending on the option set) as it reads them. The server returns EOF when detected. |
|
REMOVE DIRECTORY (rmdir) |
Deletes a directory. |
|
REMOVE FILE (remove) |
Deletes a file. |
|
RENAME FILE (rename) |
Renames a file. If the destination filename is the same as an existing filename and the destination filename does not have a zero or negative version number, the Server overwrites the existing file. |
|
READ LINK (readlink) |
Reads the contents of a symbolic link. |
|
SET ATTRIBUTES (setattr) |
Sets file attributes. The Server handles certain file attributes in ways that are compatible with the OpenVMS system. These attributes are: File protectionThe Server maps the UNIX file protection mask to the OpenVMS file protection mask, as shown earlier in this chapter. UID/GIDThe client changes the file owner's UIC. The PROXY database maps the new UID/GID to an OpenVMS UIC. If the Server cannot locate the new UID/GID in the database, it returns an error and does not change the owner UIC. SizeIf the file size is larger than the allocated size, the Server extends the file. If the size is 0, the Server truncates the file and sets the record attributes to sequential STREAM_LF. You cannot change the size of variable length or VFC files (except to zero). Access timeChanging the access time has no effect on the OpenVMS system. Modify timeThe modify time updates the OpenVMS revision time. |
|
SYMBOLIC LINK (symlink) |
Creates a symbolic link. The Server creates the file with an undefined record structure and uses an application ACE on the file to mask it as a symbolic link. |
|
WRITE TO FILE (write) |
Writes to a file. The Server does not allow a remote host to write to a directory file, or to VARIABLE and VFC files. If the Server allowed a remote host to write to an existing OpenVMS file that was not a STREAM_LF or fixed-length record format file, the file could become corrupted. The Server does not allow a remote host to explicitly change the record format of an OpenVMS file. The Server can return the non-standard NFS error ETXTBSY (26) and EINVAL (22). The Server returns ETXTBSY when an OpenVMS user has a file open for exclusive access and an NFS user tries to use the file in a way that is inconsistent with the way the OpenVMS user opened the file. The Server returns EINVAL if an NFS user tries to write to or change the size of a VARIABLE or VFC record format file. With Version 3, the server will support asynchronous writes (see commit). |
If you are experiencing network communication-related problems on the NFS v3 Server, please check the following items:
1 Make sure MultiNet is running on the OpenVMS system.
2 Confirm the RPC services running with the following command at the DCL prompt:
$ MULTINET SHOW /RPC
3 Make sure the Server is running. If not, start it by entering the following command at the DCL prompt: $ MULTINET NETCONTROL NFSV3 RESTART
4 To verify general connectivity between the two systems, try using FTP or TELNET, if purchased and installed on your system. For example, try to open a TELNET connection with the remote host in question. If another product is not available on your system, try using the PING utility.
5 Verify the internet addresses the local host and the remote hosts are using. If your local network includes a gateway, also verify the gateway address.
6 If you are experiencing problems performing NFS operations from a NFS client, check the Server's NFSV3_SERVER.LOG file. It may contain messages that can help isolate the problem.
