File Server Protocol Review: CIFS, NFS, and DAFS

When a client accesses a file on a file server or NAS filer, a file-level protocol is used. The most popular Windows and UNIX file-level protocols are CIFS and NFS, respectively. Even though the names of these protocols include file system, these are network protocols used to access file systems. These protocols define messaging semantics and syntax that enable file system interaction (such as open, read, and write operations) across a network. Of course, these protocols provide file-system functionality to applications such as open, read, and write operations. Two more popular file-level protocols are FTP and HTTP. However, these protocols are limited in functionality when compared to CIFS and NFS. FTP and HTTP do not support file locking, client notification of state change, or other advanced features supported by CIFS and NFS. FTP and HTTP can be used only to transfer files (simple read and write operations). As such, FTP and HTTP are not considered enabling technologies for modern storage networks. A new file-level protocol known as direct access file system (DAFS) recently appeared in the market. It promises to improve application performance while lowering host CPU utilization. DAFS adoption has been slowed by the requirement to modify application code. To date, DAFS adoption has been led by database application vendors.

CIFS

In Microsoft Windows environments, clients historically requested files from servers via the Server Message Block (SMB) protocol. In 1984, IBM published the basis for the SMB protocol. Based on IBM's work, Microsoft and Intel subsequently published the OpenNET File Sharing Protocol. As the protocol evolved, Intel withdrew from the effort, and the protocol was renamed the SMB File Sharing Protocol; however, SMB provides more than just file-sharing services.

SMB relies upon the services of the Network Basic Input Output System (NetBIOS) rather than Windows Sockets (Winsock) services. NetBIOS on IP networks was standardized by the IETF via request for comment (RFC) 1001 and RFC 1002 in 1987. Those RFCs enabled the use of SMB over IP networks and greatly expanded the market for SMB as IP networks began to rapidly proliferate in the 1990s. SMB remained proprietary until 1992, when the X/Open committee (now known as the Open Group) standardized SMB via the common application environment (CAE) specification (document 209) enabling interoperability with UNIX computers. Even though SMB is supported on various UNIX and Linux operating systems via the open-source software package known as Samba, it is used predominantly by Windows clients to gain access to data on UNIX and Linux servers. Even with the X/Open standardization effort, SMB can be considered proprietary because Microsoft has continued developing the protocol independent of the Open Group's efforts. SMB eventually evolved enough for Microsoft to rename it again. SMB's new name is the CIFS file sharing protocol (commonly called CIFS).

Microsoft originally published the CIFS specification in 1996. With the release of Windows 2000, CIFS replaced SMB in Microsoft operating systems. CIFS typically operates on NetBIOS, but CIFS also can operate directly on TCP. CIFS is proprietary to the extent that Microsoft retains all rights to the CIFS specification. CIFS is open to the extent that Microsoft has published the specification, and permits other for-profit companies to implement CIFS without paying royalties to Microsoft. This royalty-free licensing agreement allows NAS vendors to implement CIFS economically in their own products. CIFS integration enables NAS devices to serve Windows clients without requiring new client software. Unfortunately, Microsoft has not extended its royalty-free CIFS license to the open-source community. To the contrary, open-source implementations are strictly prohibited. This somewhat negates the status of CIFS as an open protocol.

Note that open should not be confused with standard. Heterogeneous NAS implementations of CIFS, combined with Microsoft's claims that CIFS is a standard protocol, have led to confusion about the true status of the CIFS specification. Microsoft submitted CIFS to the IETF in 1997 and again in 1998, but the CIFS specification was never published as an RFC (not even as informational). The SNIA formed a CIFS documentation working group in 2001 to ensure interoperability among heterogeneous vendor implementations. However, the working group's charter does not include standardization efforts. The working group published a CIFS technical reference, which documents existing CIFS implementations. The SNIA CIFS technical reference serves an equivalent function to an IETF informational RFC and is not a standard. Even though CIFS is not a de jure standard, it clearly is a de facto standard by virtue of its ubiquity in the marketplace.

A CIFS server makes a local file system, or some portion of a local file system, available to clients by sharing it. A client accesses a remote file system by mapping a drive letter to the share or by browsing to the share. When browsing with the Windows Explorer application, a uniform naming convention (UNC) address specifies the location of the share. The UNC address includes the name of the server and the name of the share. CIFS supports file and folder change notification, file and record locking, read-ahead and write-behind caching, and many other functions.

Note

The phrase "Universal Naming Convention" is interchangeable with "Uniform Naming Convention" according to Microsoft's website.

NFS

Sun Microsystems created NFS in 1984 to allow UNIX operating systems to share files. Sun immediately made NFS available to the computer industry at large via a royalty-free license. In 1986, Sun introduced PC-NFS to extend NFS functionality to PC operating systems. The IETF first published the NFS v2 specification in 1989 as an informational RFC (1094). NFS v3 was published via an informational RFC (1813) in 1995. Both NFS v2 and NFS v3 were widely regarded as standards even though NFS was not published via a standards track RFC until 2000, when NFS v4 was introduced in RFC 3010. RFC 3530 is the latest specification of NFS v4, which appears to be gaining momentum in the marketplace. NFS v4 improves upon earlier NFS versions in several different areas including security, caching, locking, and message communication efficiency. Even though NFS is available for PC operating systems, it always has been and continues to be most widely used by UNIX and Linux operating systems.

An NFS server makes a local file system, or some portion of a local file system, available to clients by exporting it. A client accesses a remote file system by mounting it into the local file system at a client-specified mount point. All versions of NFS employ the remote-procedure call (RPC) protocol and a data abstraction mechanism known as external data representation (XDR). Both the RPC interface and the XDR originally were developed by Sun and later published as standards-track RFCs.

DAFS

DAFS partially derives from NFS v4. The DAFS protocol was created by a computer industry consortium known as the DAFS Collaborative and first published in 2001. The DAFS protocol was submitted to the IETF in 2001 but was never published as an RFC.

The DAFS protocol is not meant to be used in wide-area networks. DAFS is designed to optimize shared file access in low-latency environments such as computer clusters. To accomplish this goal, the DAFS protocol employs remote direct memory access (RDMA). RDMA allows an application running on one host to access memory directly in another host with minimal consumption of operating system resources in either host. The DAFS protocol can be implemented in user mode or kernel mode, but kernel mode negates some of the benefits of RDMA.

RDMA is made possible by a class of high-speed, low-latency, high-reliability interconnect technologies. These technologies are referred to as direct access transports (DAT), and the most popular are the virtual interface (VI) architecture, the Sockets direct protocol (SDP), iSCSI extensions for RDMA (iSER), the Datamover architecture for iSCSI (DA), and the InfiniBand (IB) architecture. RDMA requires modification of applications that were written to use traditional network file system protocols such as CIFS and NFS. For this reason, the DAFS Collaborative published a new application programming interface (API) in 2001. The DAFS API simplifies application modifications by hiding the complexities of the DAFS protocol. The SNIA formed the DAFS Implementers' Forum in 2001 to facilitate the development of interoperable products based on the DAFS protocol.

Another computer industry consortium known as the Direct Access Transport (DAT) Collaborative developed two APIs in 2002. One API is used by kernel mode processes, and the other is used by user mode processes. These APIs provide a consistent interface to DAT services regardless of the underlying DAT. The DAFS protocol can use either of these APIs to avoid grappling with DAT-specific APIs.