NFS Design Features

Understanding certain NFS features, discussed in this section, can help you optimize NFS performance.

Inodes

UNIX uses an inode, which has a unique ID number, to record information about a file. Every file and every directory has an inode. A file can have more than one file name (depending on the number of links), but only one inode. An inode contains the following items:

• Inode number.

• File name.

• File size and type.

• Date and time of file creation, modification, and access.

• Date and time of inode modification.

• File security information (owner, group, permissions).

• Number of links.

• Block map, with pointers to the data blocks that make up the file.

File Naming

The NFS server applies the following file naming rules to NFS client requests:

• File names can be no longer than 255 characters.

• The following special characters are not permitted: < > : " / \ |.

• The server recognizes "." (current working directory) and ".." (parent of current working directory).

File Permissions

Every file has a set of permissions associated with it that determine who can access the file and what they can do with the file. (Someone with superuser or root permissions can override the permissions assigned to a file.)

Windows NT and UNIX use different mechanisms to assign permissions to files. Windows NT uses a d iscretionary access-control list (DACL) to assign permissions to files, and UNIX uses the concept of access mode. The access mode can be changed using the chmod command provided with Services for UNIX.

UNIX file access permissions permit a user to read, write, or execute a file based on the type of user attempting to perform the action, user , group , or other . Permission given to user applies to the owner of the file, group applies to members of a group of users to which the file belongs (the file is owned by the primary group of the person creating the file), and other applies to users other than the owner and members of the group of the file.

Table 11.6 File Permission Capabilities

UNIX identifies users and groups by user ID (UID) and group ID (GID). Users have a single UID and one or more GIDs, which are stored in the file / etc/passwd.

Windows NT assigns permissions to a file by adding an access control entry (ACE) to the DACL. An ACE consists of a right granted to a specific user or group. Services for UNIX maps a Windows NT DACL into a UNIX access mode based on the owner of the file and the associated ACEs. To accomplish this, the UNIX users and groups must be properly mapped to the appropriate Windows NT users and groups using the Server for NFS User Manager.

On the Windows NT–based computer, the user, johndo, is created and added to the Users group. On the UNIX computer, the user, johndo , is created and added to the Staff group. In Server for NFS, the Windows NT user, johndo , is mapped to the UNIX user, johndo ; the group, Users, is mapped to the UNIX group, Staff. The user, johndo, takes ownership of the file, letter.doc, on an exported NFS file system on the computer running Services for UNIX, grants Full Control permissions for himself and for the group, Users, and grants List permissions for Everyone. When the user, johndo , accesses the NFS file system on the computer running Services for UNIX from a UNIX-based NFS client and runs the ls   -l command on the file, letter.doc, he sees the following file listing:

rwxrwxr-x 1 johndo staff 2116 Jul 1 14:54 letter.doc

The first nine characters — in groups of three — indicate the read, write, and execute permissions for the owner (rwx), the group (rwx), and other (r-x); a hyphen indicates the absence of permission. The permissions are followed in the listing by the number of hard links (1), the user name (johndo), the group name (staff), the file size (2116), the date and time the file was last modified (Jul 1 14:54), and the file name.

Note

A special situation arises when the owner of the file is the Windows NT group Administrators. If the owner of the file is Administrators, then Server for NFS automatically maps the owner to UID 0 (root) on the UNIX-based computer.

If the owner of the file is not granted explicit permissions to the file by an ACE, the file listing shows that the owner has no access rights to the file (access mode of 0). The Server for NFS administrator can change this behavior by using the Implicit Permissions check box on the Security Permissions tab of the Server for NFS Configuration dialog box. If Implicit Permissions is selected, then Server for NFS combines the permissions for any groups in which the owner is a member and that are granted permissions to a file with the permissions for Everyone to determine the access permissions for the owner.

When a file is created in Windows NT, the file inherits the permissions of its parent directory. If either the chgrp or chmod command is run from an NFS client on an Services for UNIX server, then the default behavior for Server for NFS is to remove any existing DACL entries and write the entries for the three NFS entities (owner, group, and other) to everyone. As a result, the file loses its inherited permissions. The Server for NFS administrator can change this behavior by selecting Augment DACL in the Security Permissions tab. If Augment DACL is selected, Server for NFS also writes the inherited permissions of the parent directory.

Symbolic Links

A symbolic link is a file that points (that is, contains the path) to another file or directory. A symbolic link can point to a file or a directory on any UNIX file system accessible on the network. The system finds the linked file by reading the symbolic link and then accessing the indicated file or directory. Symbolic links are useful, for example, when a file must be accessible from more than one directory.

Symbolic links can point to an absolute path or a relative path. Since a symbolic link is resolved in terms of the link's location on the client's file system, it is possible for a symbolic link to point to a nonexistent file or directory on the client system or to files that reside in a directory that is not mounted. Such files are not accessible.

An RPC call to a server to determine the location of a symbolic link returns a path that is interpreted on the client but might point to a file system that has not been mounted by the client. If a client mounts a directory containing a symbolic link, the target must also be mounted by the client for the file to be accessible.

Client for NFS can optionally check a local, manually populated configuration file for the correct locations of the targets of symbolic links.

For example, the system administrator of a UNIX-based NFS server, server1 , creates a symbolic link named "public" that points to a fictitious directory, / server2 . The ls   -l command shows the following:

lrwxrwxrwx 2 root other 8 Jul 1 16:25 public->/server2

Then, on the computer running Client for NFS, or on a network file system that is accessible to it, the system administrator creates a text file listing anticipated symbolic links with entries like the following:

server2 \server2\sharename

When the computer running Client for NFS connects to the exported file system on server1, it resolves the symbolic link, public, and initiates an NFS connection to \server2:\sharename. This allows the client to view files stored on the remote server, server2.

File Locking

File locking allows a process to have exclusive access to a file or part of a file. File locking is implemented on the server and the client. A server restarted after a crash attempts to restore the lock status to the previous condition. If the client crashes, the server releases the lock. However, after the client restarts, it has a short period of time to reclaim the lock. When a file is locked, the buffer cache is not used for that file. Each write request is immediately sent to the server.

File locking is implemented differently under BSD UNIX compared to System V UNIX, which are the two versions of UNIX from which most current UNIX operating systems descend. BSD has a locking mechanism only for local files; System V locks are handled separately from the NFS protocol by an RPC lock daemon, lockd , and a status monitoring daemon, statd , which monitors status and provides crash and recovery functions for NFS locking. The lock daemon runs on both the client and the server to process lock requests and lock releases. The Network Lock Manager (NLM) protocol defines the communication between remote lock daemons.

File Caching

File caching involves storing frequently used information in quickly accessed memory. The UNIX buffer cache is a portion of the system's memory that is allocated for file blocks that have been recently referenced. In NFS, file caching is used on the client to eliminate some RPC requests over the network and used on the server to improve data throughput. NFS maintains data integrity despite the existence of client-side and server-side caches.

The NFS redirector uses the Windows NT system cache when it opens a file for read or read/write access. When data is written to the file, it is also written to the cache. The data is flushed to the redirector later. If an unrecoverable network error occurs while the data is being transferred to the remote server, the write request might fail. In this case, the user sees a system message.

The Windows NT cache manager also does read-ahead, in which the next file block is read in advance and stored in the buffer cache. As a result, a one-to-one mapping between an application read/write request and an NFS call does not exist.

The NFS redirector supports file locking, using the Network Lock Manager (NLM) protocol, to ensure data consistency. If file locking is disabled, data caching is enabled.

File caching is not provided on Server for NFS.