10.2. Limitations of PC/NFS
The NFS protocol is the lingua franca of file-sharing
protocols in that it is implemented on the
widest variety of operating system environments, both client and
server. These environments include Unix (nearly all of them),
Windows, NT, MacOS, MVS, OS/400, OS/2, VMS, many real-time operating
systems, and systems designed for network-attached storage, such as
the ONTAP system for Network Appliance's hardware. One reason
why NFS has been so successful is that it is very simple. This
simplicity has a price; NFS does not take the approach of supporting
every arcane, operating-specific file semantic for all the
environments it supports. Using NFS on non-Unix platforms, especially
as a client, can limit you. This is very noticeable with PC/NFS. For
example, the Windows and NT worlds have notions of enforced locking,
which NFS, even via the NFS Lock Manager, does not provide. While
PC/NFS implementations do their best to emulate this semantic and
others, you will find that some applications work in unexpected ways
over NFS.
These limitations apply to NFS Versions 2 and 3. NFS Version 4 goes a
long way toward supporting Windows and NT file semantics. At the time
of this writing, there were no known generally available NFS Version
4 implementations.
10.2.1. NFS versus SMB (CIFS)
SMB stands for Server Message Block and
is the file access protocol that is
native to Windows and NT. In 1996, Microsoft, the owner of the SMB
protocol, renamed SMB to CIFS: the Common Internet File System.
However, at the time of this writing, CIFS was not as common as NFS
when it came to came to the variety of client implementations. CIFS
is, however, growing in the number of server implementations. When
you consider the plethora of low-end, network-attached storage boxes
aimed at consumers and small office environments, that often support
CIFS but not NFS, it is arguable that CIFS has surpassed NFS in the
number of unique server implementations. The installed base of
Windows and NT desktop computers as compared to non-Windows, non-NT
desktops is a big reason for this trend.
Unix is becoming a popular platform for CIFS servers. This is likely
due to the popularity of the open source package called Samba, which
is a CIFS server for Unix platforms. Samba is developed and
maintained by a world-wide community of programmers dedicated to
producing a server as compatible with Microsoft's clients as
possible. This is no mean task; at the time of this writing, the
shared opinion of many in the CIFS server industry was that published
CIFS specifications were inadequate to build a compatible server. The
Samba developers, and no doubt other non-Microsoft implementors, have
often resorted to using packet sniffers between existing Windows and
NT clients and
servers to deduce the protocol formats and
semantics.
The emergence of Samba has led to a massive shift from deploying
PC/NFS to deploying Samba instead. This is for at least three
reasons:
- Samba is free of charge under Free Software Foundation's GNU
Public License.
- It is easier for system administrators to install and maintain Samba
on a few server hosts than to install and maintain PC/NFS on many
client hosts.
- It is perceived that SMB has better security than NFS. This is false.
Nor is it quite true to say that NFS has better security. You can
have Kerberos V5 (see Section 12.5.5.1, "Kerberos V5") security for your
collection of PC/SMB clients if all your SMB servers run Windows
2000.[15] You
can have Kerberos V5 security for certain PC/NFS clients if all your
servers support NFS secured with Kerberos V5.[16]
However, when comparing a situation where you cannot run Windows on
all your SMB servers with a situation where you cannot run NFS
servers that support Kerberos V5 or NFS/dh, (see Section 12.5.4, "AUTH_DH: Diffie-Hellman authentication"), then the SMB environment is more secure.
10.2.2. Why PC/NFS?
With the ubiquity of CIFS servers on Unix platforms, it begs the
question, why run NFS on a Windows or NT
client? This question was asked of the
comp.protocols.smb and
comp.protocols.nfs Usenet newsgroups in the
summer of 2000. The responses can be summarized as follows:
- Speed
- Some respondents claimed that NFS was faster. An article by Jeff
Ballard for Network Computing magazine's web site
("Increasing File Access Through SMB," March 6, 2000,
www.nwc.com) compared three Unix-based SMB
servers. An interesting quotation from the article is:
If it's speed you want, NFS is probably a better solution [than
SMB] for you.
Some direct research was done to investigate such claims. A 256 MB
file was created in the /tmp directory of a
Solaris 8 file server. The server was an Ultra 10, with a 440 Mhz
Ultra Sparc II processor and 512 MB of primary memory. A Windows 98
client (a Sony Vaio Z505HS, with a 500 Mhz Pentium III processor and
128 MB of primary memory) was used to copy (via Windows Explorer) the
file between the file server and client. Using Samba as the SMB
server, and native SMB client in the client, copying the file from
the server to the client's My Documents
folder took about one minute. However copying the file from the
My Documents folder to the SMB server took about
ten minutes. When using a free evaluation copy of an NFS client on
the client, and the native NFS server on the Solaris 8 system, the
respective file transfer times were about 45 seconds each. The quoted
times are qualified with "about," because Windows
Explorer did not display file transfer times, leaving the tester
timing the results with the second hand of a timepiece.
The informal results were obtained without any tuning of the Solaris
NFS server or the Samba server. It is quite possible that tuning the
Samba server would have improved performance. Also, single stream
file transfer speed is only one part of performance. About the only
conclusion you should make is that you need to consider performance
when making the decision to use NFS or SMB on Windows or NT clients.
- Administrative complexity
- Administering an SMB server is much different than administering an
NFS server. Even if you are primarily a Unix shop with some Windows
or NT clients, running an SMB server is still going to require at
least as much expertise as running an NFS server.
One respondent said if you have few (ten or less) potential SMB
clients, then you should strongly consider the trade-off of
purchasing and installing commercial PC/NFS products on Windows and
NT systems, versus devoting administration resources to SMB.
It required most of a day to install and configure the precompiled
Samba binaries on the Solaris 8 server, plus lots of fiddling on the
Windows 98 client, before the Network Neighborhood folder would
recognize the Solaris 8 server. One unexpected result was that the
passwords for SMB users apparently have to be managed separately from
the corresponding Unix passwords, due to absence of an NTLM server on
the network. This is because the Windows 98 client in the testbed was
apparently sending encrypted passwords. Since the password database
in NIS or files encrypts the passwords with a different scheme than
Windows 98, Samba provides the option to maintain a separate
database.
- Software compatibility
- One respondent claimed that there are Windows- or NT-based
applications that work only over NFS. Rational's Clearcase, a
software configuration management (source code control) system, was
found to be an example.
There is one more consideration: reliability. The SMB protocol is
based on TCP/IP and is very stateful, like the NFS lock manager.
State recovery is very simplistic; when the TCP connection between an
SMB client and server is lost, the SMB server removes all state that
belongs to the SMB client. There is no mechanism to allow a client to
reestablish state. In contrast to the NFS environment, the filing
protocol has no state to recover. The NFS environment's locking
protocol is stateful, but there is a state recovery mechanism:
clients are given a grace period to re-establish state. The
consequence of the SMB approach is that a client has a higher
opportunity to lose its locks and other valuable state after a server
restart than with the NFS environment. Andy Watson and Paul Benn, in
a white paper from Network Appliance ("Multiprotocol Data
Access: NFS, CIFS, and HTTP," TR3014, Revision 3, May 1999,
www.netapp.com), wrote:
If a CIFS client attempts file access on an established connection
while the server is unavailable (down or not yet finished rebooting),
this is effectively the equivalent of a failed disk from the
perspective of the application software. In many cases, the
application will report an error and allow the user to retry, but
some applications will simply hang or exit.
At the time this book was written, this statement was true for both
Windows ME and Windows 2000. However, there are rumors that
future
versions
of Windows will address this recovery issue.
![Previous](../gifs/txtpreva.gif) | ![Home](../gifs/txthome.gif) | ![Next](../gifs/txtnexta.gif) |
10. PC/NFS Clients
| ![Book Index](../gifs/index.gif) | 10.3. Configuring PC/NFS |