History aside, NFS has one key advantage--it works well. NFS has been around for some time and NFS version 3 adds for features that reflect the reliability of modern servers. NFS is in use around the world at all levels. It is used between two machines on their own network, all the way to serving tens to hundreds of thousands of users across the globe.

There are three main areas of focus when looking at NFS. These areas are:

NFS in the Unix world
NFS in a Windows NT world
NFS in a cross-platform world

NFS in a Unix World

NFS is both the de facto and the de jure standard method of sharing files on networks today. It is the king of the Unix hill, with every Unix offering support natively.

In enterprise-scale environments, often NFS is used in conjunction with Network Information Service (NIS). This is done to facilitate two key parts of NFS in a Unix environment: password files, and automount tables. The first, password files, is very important since NFS works with the UID (User Identifications). When you are sharing a filesystem to many machines, if you wish to give read/write access to these machines, you will need to have what is called a "UID space". A UID space is a group of computers that correlate UID numbers to logins identically. Naturally every machine does not need to have every user allowed to log into it, but each user has a single, reserved UID in the space that is reserved for them.

Another part of NIS that is used in conjunction with NFS is the auto.home map. Automounting is a method where you can specify common directories across many machines, and they will be automatically mounted when some part of the system requests a file or directory listing from the share. For instance, if /home/ballard was my home directory, and it was automounted, when I would log in, the system would mount the filesystem for me and it would be there for me to use. If I should log out, the system will notice after a few minutes of idleness that the NFS share is not being used, so it will be automatically unmounted.

Here is what the automount table might look like:
anchor> ypcat -k auto.home
kohlhepp nfshome:/users/kohlhepp
dfetters nfshome:/users/dfetters
dbackman nfshome:/users/dbackman
conover nfshome:/users/conover
ballard nfshome:/users/ballard
archive nwc-wi-edit:/users/archive
anthony nfshome:/users/anthony
survey nfshome:/users/survey
jmilne nfshome:/users/jmilne
yerxa nfshome:/users/yerxa
mlee nfshome:/users/mlee


This table will then show how the /home directory will exist. /home/ballard, /home/kohlhepp, etc., will be created as needed. Note, that if you just do a ls of this directory, you will not see all of these directories! These directories will be created on the fly, as you attempt to access them. They will exist until about 5 minutes after you no longer have any files open within the directory, at which point the system will automatically release the mount.

The automount process of NIS in conjunction with NFS is a feature that allows for a lot of information to be stored on the server, while not providing for a lot of unnecessary overhead on either the client or the server. In a large environment, like the College of Engineering at the University of Wisconsin - Madison, many directories are automounted. To have all of these directories mounted simultaneously would slow all of the clients down, and would hurt the servers. Each client would be mounting hundreds of shares to many servers, while each server would have hundreds of clients mounting them.

While it is very handy, it is easy to forget that there is a cost with accessing things within the automounted directory! If you are going to use automouting, use thought when laying out your map strategy. In the past we have seen situations where paths that point to an automounted directory are put in every user's .cshrc (the startup resource file for csh and tcsh - the default shell in this instance). Then every time someone logs in, the automount would need to be made, at quite a cost.

NFS in a Windows NT world

Ok, so you've given in to the idea of NFS for Unix machines, but what about those acres of Windows NT machines we have out there? Relax, since NFS is a cross-platform product it can be done. Of course, it remains to be seen if NFS plays well with Windows NT. Quite surprisingly, NFS support is really good--but at a price. Also, if you need it, there are NFS servers for Windows NT. Their use, however, is somewhat limited.

On the clients

First let us examine the world of NFS to the Windows NT desktop. There are many reasons to consider using NFS to your Windows NT desktops. The primary reason, is for simplifying the process of using both Unix desktops and Windows NT desktops. If your organization uses a large number of Unix machines, accessing that data from Windows NT is much easier with an NFS client.

Secondly, many people like using Unix machines as servers. While the jihad over Unix servers versus Windows NT servers is too big to fit into this Network Design Manual, there have been some benefits. Currently Unix vendors are starting to feel the pinch of Windows NT, and so the Unix vendors are starting to offer their server-class machines even cheaper than their equivalently powered Windows/Intel boxes. (Plus you get the reliability and maturity of Unix with it.)

On the servers

As we mentioned before, there are also ways of offering NFS service to your Unix machines from Windows NT. If you are looking to replace your Unix NFS servers, and think that a Windows NT NFS server is the way to go--forget it. While it might sound good to replace Microsoft's SMB with a third party NFS, the performance gain you might see is far less than the hassle of administering it.

So what does that leave Windows NT NFS servers to do? These NFS servers are pretty much for connectivity only, and really are not geared to replace Unix-based NFS servers. Where Windows NT NFS servers do fit in is for connectivity to a small network of Unix machines from a large network of Windows NT machines. Apart from that, there is not much that the NFS servers are well suited for.

Samba: The Dancing NFS killer

Unfortunately for the NFS vendors, (and fortunately for you) there is a really good replacement for NFS on the NT desktop. In fact, it is the single largest competition to any one of the NFS vendors. It is called Samba. Samba is a service that runs on a Unix server that serves Windows NT's native file access protocol, SMB (Server Message Block).

What does Samba do? Samba offers file and printing services to Windows NT desktops. Without need for any Windows NT software, all of your files can be served from a Unix machine. Samba does not run on a Windows NT server, since a Windows NT server offers the same SMB file access services.

How much does it cost? It is freeware, but this is far from saying that it is free. It comes at a price that sometimes is not obvious. Since Samba was written by a lose-knit group of individuals on the Internet, there is no one person to go to if you have bugs, feature problems, or integration problems. This is not as big of a problem as it seems, in two ways.

First, Samba is well written and is in use in many places around the world today. It is in use in production-mode in organizations where you might not expect (for instance, some large banks have been reported to be using it).

Second, there are third party vendors willing to give support to Samba if you require it. Most often they offer hourly rates, and there are vendors in almost every area. Typically, however, the services they can offer you are about the same as what a local Unix guru can offer.

NFS as the cross-platform product of choice

Apart from the use of NFS in a single-vendor environment, what about a heterogeneous environment? Can NFS handle it? Is NFS even made for my platform? Relax. NFS is available for nearly every platform available today. You can run NFS on nearly everything from the worlds smallest laptops, to Cray supercomputers. NFS is quite versatile and can handle nearly any network, even potentially unreliable ones.For instance, here in Madison, we use Netware NFS to serve NFS to our mail server (a Sun Microsystems Sparc 20). We do this mostly for convenience, as there happen to be a large number of disks there. We can also access these files then from anywhere in the network. Our PC's can either gather the data by using Netware, NFS, or transfer protocols such as FTP. Our Unix clients are then free to load their data by NFS or, again, by FTP.