NFS fully satisfies enterprise requirements for global file sharing. It supports global workgroups by keeping file systems located worldwide continuously and transparently accessible to users. An industry leader in performance, NFS provides fast access to file information as well as the scalability to support small to large network environments. Because it relies on a flexible and extensible security architecture, it enables administrators to choose the security solution that fits their environment today and to have more options in the future. The ability to administer NFS centrally reduces the time and effort it takes to perform a variety of routine administration tasks. Finally, for mission critical environments, a highly available NFS implementation is provided. These features together with the vast array of multi-vendor NFS products to choose from and a rapidly growing licensee and installed base, reaffirm that NFS is the right choice for integrating the heterogeneous enterprise both now and in the future.

Feature Summary

Table 1 NFS Feature Summary

Appendix A: NFS Fundamentals

The Mechanics of NFS

NFS employs a client/server architecture and therefore consists of a client program, a server program and a protocol that is used to communicate between the two over the network. This section describes the mechanics of NFS distributed file sharing technology including how servers share their file systems, and how clients are able to access these file systems transparently.

The NFS Server

The role of the NFS server is to allow its disk file systems to be accessed (in other words "shared") by other machines (clients) on the network. The process whereby a server makes its file systems available to be shared is called exporting, and the directories that are made available are referred to as exported file systems.

In order to export a file system, the system administrator must edit a configuration file and specify three things:

1. 1. The full pathname of the directory to be exported

1. 2. The client machines that will have access to the exported directory

1. 3. Any access restrictions

At system start up time a system dependent program (the share program on Solaris 2.X systems) is invoked that opens and reads the information in this configuration file. This program then informs the servers operating system kernel about the permissions applicable to each exported file hierarchy. A special background processes (mountd and nfsd) are invoked and wait to receive client NFS requests to access the server's file systems. After this process is complete, the server is ready to accept client requests to access its file systems.

The NFS Client

NFS clients gain access to server files by mounting the servers exported file systems. The mount process results in integrating the remote file system into the client's file system "tree" (see Figure 9). An enhanced client side service called the automounter automatically and transparently mounts and unmounts file systems on an "as needed" basis. From the user perspective, this creates an environment where server file systems are continuously accessible.

Automounter Maps and the NFS Namespace

In order for the automounter to mount a file system it needs maps that tell it what to do. A map associates a client "name" (pathname) with a file system that resides on a remote server. These client names are also called mounts or mount points because they represent the points at which server file systems will be mounted.

Collectively these mount points represent the file system namespace, or in other words the names clients use to access server file systems. In the example in Figure 9, the client name or mount point is "/home/sallyb" and the server file system is "server1:/export/home/sallyb". After the mount process is complete, users on the client system will be able to access files on server1:/export/home/sallyb by simply referencing the pathname /home/sallyb. (Note that to clients running MSDOS or Windows^TM, NFS mounts look like additional drives, e.g. D:, E:, F:, etc.)

Figure 9 How a remote file system is incorporated into the client's file system "tree".

From this description it is easy to see why configuring and maintaining automounter maps and thus the NFS namespace is at the heart of NFS administration. To reduce time and effort required to administer NFS, maps are stored and therefore administered centrally in a name service. On Solaris, either NIS+, NIS or system files may be used to store map information depending on what is installed on the network.

More extensive information on managing the NFS namespace can be found in the section called "Automounter Maps and the NFS Namespace" on page 23.

The Role of the Automounter

As stated previously, the automounter's job is to transparently mount file systems on an "as needed" basis. It can detect when a user is trying to access a file system that is not already mounted, and can react by mounting the file system according to the information provided in the map. The automounter also automatically unmounts file systems that have not been referenced in over 5 minutes.

The automounter consists of three components: the automount command, the automount daemon process called the automountd, and a special purpose virtual file system (VFS [16])) called the autofs. Figure 8 on page 23 shows the components of the automounter.

At system start up time, the automount command is invoked. It reads a master configuration map called auto_master and creates mount points in the /etc/mnttab table of mount points. Afterwards, if a user on the client system references one of those mount points (for example by trying to cd to it), autofs calls automountd and asks it to actually mount the file system. The automountd establishes communication with the NFS daemon process (nfsd) on the server, looks up the right server:path reference (for example server1:/export/home/sallyb) in /etc/mnttab, and mounts the file system at the appropriate client mount point (for example /home/sally) within the autofs file system. From then on, automount and autofs are out of the picture until and unless the file system is unmounted.

At times it may become necessary to change map information to reflect server resource reallocation on the network For more information on how the automounter enables changes to be administered easily and non-disruptively, see the section called "The Automounter" on page 22.

The NFS Protocol

The NFS protocol consists of a set of remote procedures enabling clients to manipulate remote files and directories on server systems as if they were local. Using the NFS protocol routines, clients send requests for file operations to servers, and servers respond by attempting to perform the operation (provided the user has proper permission) and then sending back successful results or error values. The NFS protocol includes a full spectrum of file operations including read, write, rename, and mkdir to name only a few.

The first version of NFS, NFS Version 1, was never released. The second version of NFS, NFS Version 2, is widely implemented on a variety of operating system and hardware platforms and comprises a large majority of the existing installed base today [17]). In 1993, a new revision of the NFS protocol, NFS Version 3, was designed and tested for the first time. NFS Version 3 offers many improvements over NFS Version 2. This topic is discussed in the section called "A New Revision to the NFS Protocol--NFS Version 3" on page 7.

Fast Error Recovery

The NFS protocol was designed for fast error recovery. The parameters to each NFS procedure call contain all of the information necessary to complete it. This not only enables NFS to recover more quickly from system and network failures, it also makes NFS easier to administer.

Machine and Transport Protocol Independence

NFS is transport independent which means it is not tied to a particular transport protocol. It can run over multiple existing protocols such as UDP and TCP today, as well as having the potential to run over new protocols in the future. The NFS protocol gains its transport protocol independence by virtue of fact that it is built on top of the Sun developed transport independent remote procedure call (TI-RPC) [18]) technology. All of the NFS procedures are implemented as TI-RPC based remote procedure calls.

Because NFS utilizes the Sun eXternal Data Representation (XDR) [19]), it is machine and language independent. XDR defines the size, byte order, and alignment of basic data types such as integer, array, union, etc. so that data can be exchanged between systems with different byte ordering conventions.

Now that you have a basic understanding of how NFS works, please continue by referring to the main text of this document.

Appendix B: Multi-Vendor NFS Products

Table 2 Sample List of Vendors Offering NFS Products

---------------------------------------------
Vendor                 OS Platform
---------------------------------------------

Amdahl                 UTS
Apple                  A/UX
Beame and Whiteside    DOS, Windows?
BSDI                   Unix
Cray                   UNICOS
DEC                    Ultrix, VMS
Dell                   SVR4
FTP Software           DOS, Windows, OS/2
Frontier Technology    DOS, Windows
Hewlett-Packard        HP-UX
IBM                    AIX, MVS
Intel                  Unix
ICL                    Unix
Net Manage             DOS, Windows
Nixdorf                TOS 35
Novell                 Netware
OSF                    OSF1
Santa Cruz Operation   SCO Unix
(SCO)                                         
SunSoft                Solaris, DOS, Windows
Silicon Graphics       IRIX
Process Software       VMS
Sony                   NeWS
Texas Instruments      TI SVR3.2
TGV                    VMS
---------------------------------------------

Glossary

Access Control Lists (ACLs)

A list that indicates what type of access will allowed for a file. For example it indicates whether certain individuals or groups of individuals will be allowed to perform file operations such as read, write, execute, etc.

Authentication Service

A security mechanism that determines if someone is who they claim to be before he/she is allowed to use resources. Typically involves checking for information known only to that individual, for example a password.

Authorization Service

A security mechanism that determines if someone has permission to do what they want to do once they have been properly authenticated. Permission bits and ACLs are examples of different types of authorization.

AutoClient (Solstice)

A new, low cost client configuration with limited disk space that utilizes CacheFS technology to reduce server disk access requirements and associated network traffic by caching frequently accessed data on an "as needed" basis.

Autofs Automounter

The most recent version of the automounter which is implemented as a virtual file system (VFS).

Access Transparency

The ability to access a remote resource automatically, without being aware that it is located remotely.

Automounter

A component of client side NFS that is responsible for transparently mounting and unmounting server file systems on behalf of client requests.

Automount Command

When it is invoked at system start up time, the automount command creates mount points in the /etc/mnttab table of mounts. It can also be invoked after editing the auto_master map to mount, remount or unmount mount points.

Cache

A fast access, temporary storage area (physical memory and/or disk) utilized by an NFS client to increase the speed of access to file data. When file data is cached on the local system, client performance is improved because clients spend less time querying the server and/or waiting for the server to transfer data over the network.

CacheFS (Cache File System)

A technology on Solaris and utilized by NFS that allows client disk to be used as a cache, thereby increasing the total amount of cache space available for files.

Connectathon

An event regularly sponsored by SunSoft that enables vendors to come together and test their NFS implementations in a confidential atmosphere.

Data Encryption Standard (DES) Authentication

A private key encryption algorithm originally developed by IBM which became a national standard in the 1970s.

X/Open Federated Naming (XFN)

An X/Open specification defining policies for naming objects including users, hosts, organizations and services in a logical, hierarchical manner, making object location easier and more intuitive. XFN also enables the federation of multiple, autonomous naming services and includes an API that gives applications access to multiple, arbitrary name services.

Diffie-Hellman Authentication

A public key encryption algorithm developed by Whitfield Diffie and Martin Hellman in 1976 that is utilized by NFS on Solaris as part of an authentication service.

Encryption

A mechanism for converting information into a non-readable form so that it cannot be interpretated by an unauthorized recipient. This is accomplished by applying an encryption algorithm with a special value (known as a key) to the data.

Federated Naming Servie (FNS)

The first implementation of XFN on Solaris. (See X/Open Federated Naming)

Global Namespace (File System)

A a file system namespace that has the property that file pathnames are valid throughout the network. (See namespace)

GSSAPI

The Generic Security Service Application Program Interface (GSSAPI) provides a standard framework for uniting multiple authentication flavors under a single API. It is described in Internet RFC 1508.

Highly Available NFS

A version of NFS that is tolerant of system and network failures.

Kerberos

An authentication service developed by MIT for project Athena that utilizes private and public key mechanisms to exchange authentication information contained in expanded packages called "tickets".

LADDIS

See SPECsfs.

Lock Manager

A file locking service provided with NFS that can prevent or control concurrent access to files. See Status Monitor.

Map (Automounter)

A table or file which associates client pathnames with server file systems enabling the automounter to mount file systems on behalf of client requests.

Mount Point

The point in the client file system tree at which a server file system will be mounted. Also called a "mount" or client "name" (pathname).

NIS

Formerly yellow pages or YP, a naming service on Solaris designed to allow centralized administration of heterogeneous client/server networks.

NIS+

A replacement for NIS. An enterprise naming service that provides a secure, robust repository of information about network entities such as users, servers and printers, enabling efficient administration of enterprise client/server networks.

Namespace (File System)

Collective names (or pathnames) clients use to access server file systems. (See mount point.)

Permission Bits

On Unix systems, permission bits are associated with files. These permission bits indicate whether read, write and/or execute permission is allowed for the file's owner, members of certain groups, or everyone.

Public Key Encryption Service

An encryption service in which the key or value used to encrypt data is different than the key or value used to decrypt information.

Private Key Encryption Service

An encryption service in which the key or value used to encrypt data is the same as the key or value used to decrypt information.

Reliable/Unreliable Transport Protocol

A reliable transport protocol is one that ensures data reaches its destination despite possible network errors and transmission delays. An unreliable protocol does not provide a guarantee that data will reach its destination. Mechanisms to ensure data delivery must therefore be built in to the application or service layer when unreliable protocols are utilized.

Safe Asynchronous Writes

The capability provided in NFS Version 3 that enables clients to write data safely and asynchronously to the server without waiting for the data to be committed to stable storage.

Single Point of Failure

On systems with a redundant hardware configuration, if one system in the configuration fails, it is considered a single point of failure. The other system in the configuration then takes over for the one that failed.

SPARC

Scalable Processor ARChitecture. A high speed, reduced instruction set CPU architecture developed by Sun Microsystems.

SPEC

An organization including represenatives from different vendors that oversees the testing and reporting of performance figures for a variety of technologies including NFS. (Is this right? XX)

SPECsfs

A non-profit organization formed to `establish, maintain and endorse a standardized set of relevant benchmarks that can be applied to the newest generation of high performance computers'.

Status Monitor

Works in conjunction with the Lock Manager by providing host status information which determines what will be done with locks if the client or server crashes with locks in place.

Transmission Control Protocol (TCP)

A reliable transport layer service developed by the Department of Defense and utilized by NFS for communication over LANs and WANs.

Transport Independent RPC (TI-RPC)

A transport independent remote procedure call (RPC) mechanism developed by Sun and described in Internet RFC 1057. Enables applications to make procedure calls that will be executed on a remote system.

Trusted Host

A host with significant physical protection such that the information it contains is not accessible by the average user. Runs minimum configuration of software that minimizes vulnerability to intruder attack over the network.

UDP

An unreliable transport layer service developed by the Department of Defense and utilized by many existing NFS implementations for communication over LANs.

Virtual File System (VFS)

An abstract interface between the operating system and the file system that allows multiple underlying file system types (both local and remote) to be integrated.

References

Bhide, A., E.Elnozahy, S. Morgan, "A Highly Available Network File Server", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA January 1991

Blaze, M., "Key Management in an Encrypting File System", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA June 1994

Borr, A. and C. Wilhelmy, "Highly Available Data Services for UNIX Client- Server Networks: Why Fault Tolerant Hardware isn't the Answer", Hardware and Software Architectures for Fault Tolerance: Experiences and Perspectives, Lecture Notes in Computer Science, Vol. 774, pp.285-304, Springer-Verlag, Berlin, 1994

Cache File System White Paper, URL:http:/www.sun.com/software/Products/Solaris-white- papers/cachefs_wp.html

Callaghan, Brent, NFS: A Technical Update, Sun Microsystems Press, 1995

Callaghan, Brent, and Tom Lyon, "The Automounter", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1989

Callaghan, Brent, and Satinder Singh, "The Autofs Automounter", Summer USENIX Conference Proceedings, USENIX Association, Berkeley, CA, June 1993

Digital Equipment Corporation, "Guide to Prestoserve", DEC OSF/1 Prestoserve Product Documentation, Order number AA-PQTOA-TE, March 1993

Hitz, D., J. Lau, M. Malcolm, File System Design for an NFS File Server Appliance, Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1994

Keith, Bruce and Wittle, Mark, "LADDIS: The Next Generation in NFS File Server Benchmarking", Summer USENIX Conference Proceedings, USENIX Association, Berkeley, CA, June 1993

Khanna, Raman, Distributed Computing Implementation and Management Strategies, Prentice Hall, 1993

Kleiman, S.R., "Vnodes: An architecture for Multiple File System Types in Sun Unix", USENIX Conference Proceedings, Atlanta, Summer 1986

Linn, J., "Generic Security Service Application Program Interface", RFC-1508, September, 1993

Macklem, Rick, "Lessons Learned Tuning the 4.3BSD Reno Implementation of the NFS Protocol", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1991

Macklem, Rick, "Not Quite NFS, Soft Cache Consistency for NFS", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1994

Minnich, Ronald, "The AutoCacher: A File Cache Which Operates at the NFS Level", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1994

Moran, J., R. Sandberg, D. Coleman., J. Kepecs, B. Lyon, "Breaking Through the NFS Performance Barrier", Proceedings of the 1990 Spring UNIX Users Group, Munich, Germany, pp. 199-206, April 1990

Pawlowski, B., Chet Juszczak, Peter Staubach, Carl Smith, Diane Lebel, David Hitz, "NFS Version 3 Design and Implementation", Winter USENIX Conference Proceedings, USENIX Association, Berkeley, CA, January 1994

Schneier, Bruce, Applied Cryptography, John Wiley and Sons, 1994

Stern, Hal, Managing NFS and NIS, O'Reilly, June 1991

Sun Microsystems, Inc., "Network Filesystem Specification", RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA (This is the NFS Version 2 specification)

Sun Microsystems, Inc., "Remote Procedure Call Specification", RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA (This is the remote procedure protocol specification)

Sun Microsystems, Inc., External Data Representation Specification, RFC-1094, DDN Network Information Center, SRI International, Menlo Park, CA (This is the proposed standard for canonical format for data exchange used with RPC)

SunSoft, "The NFS Version 3 Protocol Specification", Internet locations: ftp.uu.net:/networking/ip/nfs/NFSV3.spec.ps.Z bcm.tmc.edu:/nfs/nfsv3.ps.Z gatekeeper.dec.com:/pub/standards/nfs/nfsv3.ps.Z

Welch, Brent B., "Measured Performance of Caching in the Sprite Network File System", University of California, Berkeley

X/Open Company, Ltd., X/Open CAE Specification: Protocols for X/Open Internetworking: XNFS, X/Open Company Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United Kingdom, 1991 (This is an invaluable reference for NFS Version 2 and accompanying protocols including the Lock Manager and the Portmapper)

X/Open Company, Ltd., Developer's Specification: Protocols for X/Open PC Interworking: (PC)NFS, X/Open Company Ltd., Apex Plaza, Forbury Road, Reading Berkshire, RG1 1AX, United Kingdom, 1990

Footnote 16
For more information on virtual file systems technology, see Kleiman, S.R., "Vnodes: An architecture for Multiple File System Types in Sun Unix", USENIX Conference Proceedings, Atlanta, Summer 1986

Footnote 17
For more information on the NFS Version 2 protocol, see Internet RFC 1094

Footnote 18
For more information on TI-RPC, See Internet RFC 1057

Footnote 19
Footnote 19 X/Open standard #?