The dynamics of a distributed network are challenging to those who are in charge of installing, configuring, and maintaining them. Distributed file systems must be selected based not only on their ability to provide fast, easy, and consistent access to information throughout the global network, but also based on their ability to easily manage change. Tasks such as adding, deleting, relocating and changing file system configuration information should be streamlined or at best automated. Finally, it should be possible to administer the file system centrally, thus minimizing time and effort required keep the distributed file service up and running.

The Automounter

The automounter eases the administrative burden in many ways. Foremost is its ability to automatically mount and unmount file systems in response to client demand without requiring administrator intervention. Equally important is the ability of the automounter to query a name service (for example NIS+ or NIS on Solaris) for map information, enabling centralized administration of the NFS namespace.

The latest implementation of the automounter, sometimes referred to as the autofs automounter, offers improvements in performance and the ability to manage change. Because the autofs automounter is implemented as a virtual file system (VFS), file systems are mounted "in place", in other words on the mount points named in the automounter maps. This means the automounter no longer requires the use of symbolic links and therefore client pathnames no longer exhibit references to /tmp_mnt. Doing away with symbolic links also improves performance by eliminating the need for symbolic link traversal [9]).

Figure 8 The new autofs automounter

The autofs automounter also enables mount points to be changed without restarting the automounter or rebooting the client. After making the appropriate changes to the master configuration file auto_master, all that is required is to invoke the automount command. The automount program compares the information in auto_master with the list of mount points in the system mount table /etc/mnttab. It resolves any differences by mounting, unmounting or remounting mount points.

As before, changes to maps such as auto_home that control the majority of mounted file systems accessible by users on the network, can be implemented transparently. Edits to these maps will become effective the next time the file system is mounted by the client.

Automounter Maps and the NFS Namespace

Automounter maps provide client pathname to server file system associations or mappings. The automounter converts these maps into mounts that are added to the client's file system "tree". Therefore, the maps define the file system namespace or in other words the names clients will use to access server file systems. When care is taken to construct the namespace appropriately, users can more easily find and access files in a distributed file sharing environment.

The NFS namespace is flexible and can be tailored to suit the specific needs of different environments. Administrators can establish their own naming policies for mounted file systems so that users will be able to locate files quickly and easily. For example, it may be desirable to set up all users home directories under /home/username or all shared engineering files under /eng/shared.

The NFS namespace is also a global or shared namespace. This means that the client pathnames are valid throughout the network. Users are thus free to move to different network locations and still access files and directories using the same pathnames they used when they were on their home system. The same is true of applications that are invoked from different client systems on the network.

Perhaps one of the most useful examples of a shared or global namespace is that exhibited by the use of /home. In this case, the policy for home directory names is that they will be accessible to clients using the pathname /home/username from anywhere on the network.

Setting up a shared namespace for /home requires two steps. First an entry is made in auto_master which associates the mount point /home to a map called auto_home:

• /home auto_home

Auto_home is a map that associates user names to home directories on their respective servers:

• sally server1:/export/home/sally

• greg server1:/export/home/greg

• tom server2:/export/home/tom

• grace server3:/export/home/grace

Users can be added or deleted from the namespace by adding or subtracting them from the auto_home map. Any changes will be automatically implemented the next time the file system is mounted.

SunSoft recommends the use of shared names such as /home and /net which are covered at length in the NFS Administration Manual. However as mentioned earlier, administrators also have the freedom to establish their own naming policies for file systems and thus tailor the NFS shared namespace to suit the needs of their environment.

Using the Federated Naming Service (FNS) to Manage the NFS Namespace

As an alternative to using automounter maps, it is also possible to manage the NFS namespace according to the guidelines encompassed by the X/Open Federated Naming Specification (XFN) [10]). XFN enables the policies and administration of a file system namespace to be integrated into those of the overall enterprise. In addition, XFN creates naming consistency within each application that uses it, and therefore fosters coherence among those applications.

The integration of the file system namespace into the enterprise name space requires the federation of multiple, autonomous naming services. XFN enables the federation of these name services by providing the following:

• A way for users and applications to compose names from different naming services

• A compact set of naming policies that creates a logical, consistent namespace for the global enterprise

• An API that gives applications access to multiple, arbitrary naming services

The XFN policies enable "objects" such as users, hosts, organizations and services to be named in a logical and hierarchical manner. For instance, a user may be named relative to the organization she is in, and a directory may then be named relative to that user. As an example, the project directory of a user Jane in the software division of an enterprise with NIS+ installed on the network might be accessed by:

% cd /xfn/_org/software.eng/_user/jane/_fs/project

The organization name "software.eng" in this example is a NIS+ domain name and the notation "_fs" indicates a file system.

Files from other organizations within the NIS+ hierarchy may be accessed in a similar fashion. In addition, users in the same organization as Jane have the option of using a shorthand notation that looks like the following:

% cd /xfn/_user/jane/_fs/project

Files in other enterprises may be accessed through a global naming service such as X.500 or, in the following example, DNS:

% cd /xfn/.../wiz.com/_org/finance/_fs/payroll

This example also demonstrates how XFN allows files to be associated with organizations, not just users or hosts. Each sub-organization may have its own private files, while their parent organization maintains the files that all of them share. Files are named in an intuitive and natural manner relative to the objects with which they are associated.

XFN has garnered support from a variety of vendors including IBM, SunSoft, Hewlett-Packard, Digital, OSF and Siemens Nixdorf who are all participating in defining the standard via the X/Open process. SunSoft is providing its first implementation of XFN in Solaris 2.5. Called the Federated Name Service (FNS), it's use is optional and requires that NIS+ be installed and running on the network.

Support for Replica Servers

Replica servers are servers with duplicate file systems that can be substituted in the event that the server in use becomes unavailable. NFS currently supports replication of read-only file systems. A map entry for a read-only file system may describe several locations for alternative replica servers. At mount time, the automounter mounts the file system on the server that has the nearest proximity to the client. This reduces network routing delays and helps keep NFS traffic off the corporate backbone.

The current support for replication will be extended to allow full dynamic client failover in a future release of Solaris. The benefit of full dynamic client failover is that in the event of a server or network failure, a client will quickly and transparently be switched over to a replica server.

Low Cost NFS Client Support

NFS servers have the ability to support familiar diskless and dataless client systems on the network as well as a new client configuration called the Solstice AutoClient. In addition to lowering the cost per seat on the desktop, these configurations simplify administration by centralizing frequently required tasks such as performing system backups.

Diskless clients download the OS from the server into local RAM and then utilize the server disk for root and swap space as well as to store the user file system hierarchy (/usr). Dataless clients contain a limited amount of disk space which contains root, swap, and /usr partitions but all other user data is stored on the server. Although the cost savings and administration benefits of these configurations are clear, demand for frequently needed data on the server can greatly impact network congestion.

A new option from SunSoft called the Solstice [11]) AutoClient offers another low cost alternative that preserves the advantages of traditional diskless and dataless desktops as well as addressing many of their shortcomings. Using high performance CacheFS technology, Solstice AutoClients substantially reduce server disk access and associated network traffic by caching frequently used data such as root, swap, and user files on an "as needed" basis. Because root and usr partitions for a number of clients are centralized on the server, system software upgrades are easier and client disk requirements are drastically reduced. As with dataless clients, desktop backups are unnecessary and AutoClients are field replaceable units (FRUs)--if a disk crashes, a new one can be plugged in and work can resume after the system is restarted. This configuration offers the best of both worlds in terms of performance and administration. There is no longer any need to sacrifice one for the other.

Footnote 11
Solstice is SunSoft's recently announced strategy for enterprise management.