NFS and CIFS Protocols for Network File Systems

The differences between UNIX and Windows clients and file systems resulted in different protocols being developed for network file systems. This is not so hard to understand. If the end node processes differ, the protocols to exchange data between those end processes could also be differentand they are.

The protocol developed for UNIX environments is NFS, and the protocol developed for Windows is now called Common Internet File System (CIFS).

NFS

NFS is an approved industry standard, with many companies contributing to its development in the last 20 years. That said, NFS is mostly a UNIX standard that has not been strongly supported and implemented by Microsoft in its products due to the lack of support for Windows file semantics in NFS. The lack of Windows support in legacy NFS is not surprising when you consider that it was being developed at the same time as the original IBM PC and DOS (disk operating system).

The historical context for technology development is always influential. When NFS was initially developed, LAN technology was in its relative infancy, and errors were much more common. Therefore, NFS was initially designed as a stateless protocol for reliable and fast service in early LAN environments where clients and servers could lose network connections. If a client became disconnected from a server (and the file it was working on), it could simply try to access it again later after the connection was reestablished. In the meantime, other systems were allowed to access the file and work on it.

The transport protocol selected for NFS was the User Datagram Protocol (UDP), a fast, connectionless, lightweight protocol restricted for use to a single Ethernet network. The third generation of NFS added support for TCP, allowing NFS traffic to be integrated more closely with TCP/IP networks.

NFSV4

NFS is now in its fourth iteration, not surprisingly called NFSV4. There are many changes in NFSV4, mostly related to becoming more compatible with Windows client systems. Among the advancements in NFSV4 are

• Support for Windows metadata and access permissions that allow Windows clients to store data without losing metadata

• Stateful processes, based on the assumption that networks are reliable and to be compatible with Windows client processes

• Byte-range locking within filesagain consistent with Windows client processes

• Lock leases to eliminate locks being held for extended periods of time after a client or connection failure

• Integrated locking within NFS to eliminate the need for NFS's network lock manager (NLM)

• Compound remote procedure calls to aggregate commands and achieve more efficient network operations

• Improved security mechanisms in response to general network security threats

While NFSV4 makes NFS mostly compatible with Windows, it is not clear how widely the NFSV4 software will be implemented in Windows client systems. Microsoft could choose to include it at some point, but Microsoft has different network file system technologies it is trying to develop and promote.

CIFS

In contrast to NFS, Microsoft's CIFS protocol is not an industry standard, and Microsoft has rejected attempts by the industry to create a standards organization around it. CIFS and its future derivations are core technologies for future operating file system developments at Microsoft, and Microsoft doesn't want to compromise its product developments through a standards committee process.

The origin of CIFS can be tied to the IBM PC LAN program, which was introduced in 1985 for peer-to-peer file sharing in Token Ring networks. The protocols used in this product were adopted by Microsoft and introduced in the early 1990s as the Server Message Block (SMB) protocol of its LAN Manager product. SMB included printing and other network services in addition to its network file system technology. SMB was repeatedly reworked by Microsoft for its server products and became known as CIFS in the late 1990s.

Windows desktop operating systems since Windows 95 all support some version of SMB or CIFS. That means the majority of desktop systems in use today have a free client for Windows network file systems.

CIFS is a stateful protocol that assumes client/server connections are reliable. If a client/server connection is broken, the processing context using that connection is saved in both the client and the server. Microsoft's vision for CIFS is broader than network file system functionality and includes distributed client/server applications where processes are split between clients and servers. A stateful protocol allows clients and servers to resynchronize their work after a temporary network error.

SMB initially was designed to run on top of the NetBIOS protocol, mostly as a way to identify network resources. Today CIFS runs directly on TCP/IP without NetBIOS and uses network domain services to locate and identify resources. CIFS is routable, allowing servers and clients to be in different IP networks. The concept of domain services for locating network file system resources is tightly coupled with CIFS networks.

Locking Differences Between NFS and CIFS

While locking is primarily a file system function, the semantics of locking need to be implemented in some sort of protocol to extend that function to clients of network file systems. The protocol could be the same as the one used to access files, or it could be independent. The NFS and CIFS protocols have taken distinctly different approaches to locking, which has caused considerable heartburn in the network storage industry for several years.

NFS's implementation of advisory locking does nothing to prevent multiple clients from accessing and updating a particular file. Advisory locking depends on client applications that have the ability to recognize when locks exist and inform their users that there could be a conflict. In other words, the user is advised that a lock condition is intended. Users can update the file as they wish, because advisory locking does nothing to prevent updates in the server file system.

For reasons related to file system internals, the separate locking protocol NLM was developed to implement locking with NFS. The necessity and complexity of using two protocols to provide locking resulted in many application developers ignoring it altogether.

NFSV4 has overhauled the locking mechanism of NFS with the implementation of a lease mechanism that depends on client systems renewing their lease at regular intervals. If the lease between a client and server is broken, the server removes the lock.

In contrast, CIFS extends the strong locking semantics of Windows file systems to clients. Strong locking refers to the ability of a file system to restrict the read and update access granted to clients. You might have had firsthand experience with strong locking if you have ever attempted to open a file in a Windows network file system that was locked by another user. A message indicating the file cannot be opened or can be opened only as a read-only version is generated by the Windows file system and communicated by the CIFS protocol.

Windows systems have an access priority that is determined by the order in which clients access a file. The first client that accesses a file gets to determine the access rights of other clients that attempt to access the file later. Locking is secondary to access permissions in Windows systems. Clients that do not have the proper credentials to access a certain file cannot gain access to it through a separate lock resolution process.