A New Network File System is Born: Comparison ofSMB2, CIFS and NFS

Steven M. FrenchIBM

Samba Teamsfrench@us.ibm.com

Abstract

In early 2007, SMB2 became the first widelydeployed network file system protocol sinceNFS version 4. This presentation will compareit with its predecessors (CIFS and SMB) as wellas with common alternatives. The strengths andweaknesses of SMB/CIFS (the most widely de-ployed network file system protocol) and NFSversions 3 and 4 (the next most popular proto-cols) and SMB2 will be described.

Now that the CIFS POSIX Protocol exten-sions are implemented in Linux kernel, Samba,and multiple operating systems, whether SMB2would be better for Linux in particular thanthese CIFS POSIX Protocol extensions can beanalyzed. In addition, some of the alternativessuch as HTTP, WebDav and cluster file systemswill be reviewed. Implementations of SMB2 sofar include not just Vista and Longhorn but alsoSamba client libraries and decoding support al-ready is available in Wireshark. Linux imple-mentation progress and alternatives for SMB2client and server will also be described, andrecommendations made for future work in thisarea.

1 Introduction

The SMB2 protocol, introduced in MicrosoftVista this year, is the default network file sys-tem on most new PCs, and differs from its pre-decessors in interesting ways.

Although a few experimental network filesystem protocols were developed earlier, thefirst that were widely deployed date from themid-1980s: SMB (by IBM, Microsoft andothers), AT&T’s RFS protocol, AFS fromCarnegie-Mellon University, NFS version 2(from Sun)[1] and Novell’s NCP. The rapid in-crease in numbers of personal computers andengineering workstations quickly made net-work file systems an important mechanism forsharing programs and data. More than twentyyears later, the successors to the ancient NFSand SMB protocols are still the default networkfile systems on almost all operating systems.

Even if HTTP were considered a network filesystem protocol, it is relatively recent, datingfrom the early 1990s, and its first RFC [RFC1945] was dated May 1996. HTTP wouldclearly be a poor protocol for a general pur-pose network file system on most operating sys-tems including Linux. Since HTTP lacked suf-ficient support for "distributed authoring" with-out locking operations, with little file meta-

1

data and lacking directory operations, "HTTPExtensions for Distributed Authoring – WEB-DAV" (RFC 2518) was released in February1999, but WEBDAV did not displace CIFS orNFS, and few operating systems have a usablein-kernel implementation of WEBDAV.

So after more than twenty years, despite the in-vention of some important cluster file systemsand the explosion of interest in web servers, weare almost back where we started, comparingNFS [3] Version 4 with the current CIFS exten-sions and with a new SMB—the SMB2 proto-col. File systems still matter; network file sys-tems are still critical in many small and largeenterprises. File systems represent about 10%(almost 500KLOC) of the 2.6.21 Linux Ker-nel source code, and are among the most ac-tively maintained and optimized components.The nfs1 and cifs modules are among the largerin-kernel file systems. Network file systemsmatter—the protocols that they depend on aremore secure, more full featured and much morecomplex than their ancestors, and some of thebetter NAS2 implementations can perform aswell as SAN and cluster file systems for keyworkloads.

2 Network File System Character-istics

Network protocols can be considered to be lay-ered. Network file system protocols are thetop layer, far removed from the physical de-vices such as Ethernet adapters that send bits

1lowercase “nfs” and “cifs” are used to refer to theimplementation of the NFS and CIFS protocol (e.g.,for Linux the nfs.ko and cifs.ko kernel modules),while uppercase “NFS” and “CIFS” refer to the networkprotocol

2Network Attached Storage (NAS) servers areclosely related to network file servers.

over the wire. In the Open System Interconnec-tion (OSI) model, network file system protocolswould be considered as layer 6 and 7 (“Presen-tation” and “Application”) protocols. Networkfile system protocols rely on lower level trans-port protocols (e.g., TCP) for reliable deliveryof the network file systems protocol data units(PDUs), or include intermediate layers (as NFShas done with SunRPC) to ensure reliable de-livery.

Network file system protocols share some fun-damental characteristics that distinguish themfrom other “application level” protocols. Net-work file system clients and servers (andthe closely related Network Attached Storage,NAS, servers) differ in key ways from clusterfile systems and web browsers/servers.

• Files vs. Blocks or Objects: This dis-tinction is easy to overlook when com-paring network file system protocols withnetwork block devices, cluster file sys-tems and SANs. Network file systemsread and write files not blocks of storageon a device. A file is more abstract—acontainer for a sequential series of bytes.A file is seekable. A file conventionallycontains useful metadata such as ACLsor other security information, timestampsand size. Network file systems requestdata by file handle or filename or identi-fier, while cluster file systems operate onraw blocks of data. Network file systemprotocols are therefore more abstract, lesssensitive to disk format, and can more eas-ily leverage file ownership and security in-formation.

• Network file system protocol operationsmatch local file system entry points:Network file system protocol operationsclosely mirror the function layering of thefile system layer (VFS) of the operatingsystem on the client. Network file system

2

operations on the wire often match oneto one with the abstract VFS operations(read, write, open, close, create, rename,delete) required by the operating system.The OS/2 heritage of early SMB/CIFS im-plementations and the Solaris heritage ofNFS are visible in a few network file sys-tem requests.

• Directory Hierarchy: Most network filesystems assume a hierarchical namespacefor file and directory objects and the direc-tories that contain them.

• Server room vs. intranet vs. Internet:Modern network file system protocolshave security and performance featuresthat make them usable outside of theserver room (while many cluster file sys-tems are awkward to deploy securelyacross multiple sites), but HTTP and prim-itive FTP are still the most commonlychoices for file transfers over the Internet.Extensions to NFS version 4 and CIFS(DFS) allow construction of a global hi-erarchical namespace facilitating transpar-ent failover and easier configuration.

• Application optimization: Because thepattern of network file system protocolrequests often more closely matches therequests made by the application thanwould be the case for a SAN, and sincethe security and process context of mostapplication requests can be easily deter-mined, network file system servers andNAS servers can do interesting optimiza-tions.

• Transparency: Network file systems at-tempt to provide local remote transparencyso that local applications detect little orno difference between running over a net-work file system and a local file system.

• Heterogeneity: Network file systemclients and servers are often implemented

on quite different operating systems;clients access files without regard to theiron-disk format. In most large enterprises,client machines running quite different op-erating systems access the same data onthe same server at the same time. TheCIFS (or NFS) network file system clientthat came by default with their operatingsystem neither knows nor cares about theoperating system of the server. Sambaserver has been ported to dozens of op-erating systems, yet the server operatingsystem is mostly transparent to SMB/CIFSclients. Network file systems are every-where, yet are not always seen when run-ning in multi-tier storage environments.They often provide consistent file ac-cess under large web servers or databaseservers or media servers. A network filesystem server such as Samba can easilyexport data on other network file systems,on removable media (CD or DVD), or ona local file system (ext3, XFS, JFS)—andwith far more flexibility than is possiblewith most cluster file systems.

Network file systems differ in fundamentalways from web clients/servers and cluster filesystems.

2.1 History of SMB Protocol

Invented by Dr. Barry Feigenbaum of IBM’sBoca Raton laboratory during the early devel-opment of personal computer operating systemsoftware, who briefly named it after his initials(“BAF”) before changing the protocol name to“Server Message Block” or SMB. IBM pub-lished the initial SMB Specification book at the1984 IBM PC Conference. A few years later acompanion document, a detailed LAN Techni-cal Reference for the NetBIOS protocol (which

3

was used to transport SMB frames), was pub-lished. An alternative transport mechanism us-ing TCP/IP rather than the Netbeui frames pro-tocol was documented in RFCs 1001 and 1002in 1987.

Microsoft, with assistance from Intel and 3Comearly on, periodically released documents de-scribing new “dialects” of the SMB protocol.The LANMAN1.0 SMB dialect became the de-fault SMB dialect used by OS/2, and at leasttwo other dialects were added for subsequentOS/2 versions.

In 1992 X/Open CAE Specification C209 betterdocumented this increasingly important stan-dard. The SMB protocol was the default net-work file system for DOS and Windows, butalso for OS/2. IBM added Kerberos and Direc-tory integration to the SMB protocol in its DCEDSS project in the early 1990s. A few yearslater Microsoft also added Kerberos security totheir SMB security negotiation for their Win-dows 2000 products. Microsoft’s Kerberos au-thentication encapsulated service tickets usingSPNEGO in a new SMB SessionSetup variant,rather than using the original SecPkgX mech-anism used by earlier SMB implementations(which had been documented by X/Open). TheSMB protocol increasingly was used for pur-poses other than file serving, including re-mote server administration, network printing,networking messaging, locating network re-sources and security management. For thesepurposes support for various network interpro-cess communication mechanisms was added tothe SMB protocol, including Mailslots, NamedPipes, and the “LANMAN RPC.” Eventuallymore complex IPC mechanisms were built al-lowing encapsulating DCE/RPC traffic overSMB (even supporting complex object modelssuch as DCOM).

In the mid 1990’s the SMBFS file system forLinux was developed. Leach and Naik au-thored various CIFS IETF Drafts in 1997, but

soon CIFS Documentation activity moved toSNIA. Soon thereafter CIFS implementationswere completed for various operating systemsincluding OS/400 and HP/UX. The CIFS VFSfor Linux was included in the Linux 2.6 kernel.After nearly four years, the SNIA CIFS Tech-nical Reference[4] was released in 2002 and in-cluded not just Microsoft extensions to CIFS,but also CIFS Unix and Mac Extensions.

In 2003 an additional set of CIFS Unix Exten-sions was proposed, and Linux and Samba pro-totype implementations were begun. By 2005Linux client and Samba server had added sup-port for POSIX ACLs,3 support for POSIX4

path names, a request to return all informationneeded by statfs, and support for very large readrequests and very large write responses.

In April 2006 support for POSIX (rather thanWindows-like) byte range lock semantics wereadded to the Samba server and Linux cifs client(Linux Kernel 2.6.17). Additional CIFS exten-sions were proposed to allow file I/O to be bet-ter POSIX compliant. In late 2006 and early2007, joint work among four companies andthe Samba team to define additional POSIX ex-tensions to the CIFS protocol led to creationof a CIFS Unix Extensions wiki, as well asimplementations of these new extensions[8] inthe Linux CIFS client and Samba server (Macclient and others in progress). The CIFS proto-col continues to evolve, with security and clus-tering extensions among the suggestions for the

3“POSIX ACLs” are not part of the official POSIXAPI. POSIX 1003.1e draft 17 was abandoned beforestandardization

4In this paper, “POSIX” refers narrowly to the fileAPI semantics that a POSIX-compliant operating systemneeds to implement. When the file system uses the CIFSnetwork file system protocol, providing POSIX-like fileAPI behavior to applications requires extensions to theCIFS network protocol. The CIFS “POSIX” ProtocolExtensions are not part of the POSIX standard, rather aset of extensions to the network file system protocol tomake it easier for network file system implementationsto provide POSIX-like file API semantics.

4

next round of extensions. As the technical doc-umentation of these extensions improves, moreformal documentation is being considered.

2.2 History of NFS Protocol

NFS version 1 was not widely distributed, butNFS version 2 became popular in the 1980s,and was documented in RFC 1094 in 1989. Ap-proximately 10 years after NFS version 2, NFSversion 3 was developed. It was documented[2]by Sun in RFC 1813 in 1995. Eight yearslater RFC 3530 defined NFS version 4 (obso-leting the earlier RFC 3010, and completing anearly five year standardization process). Anextension to NFS version 3, “WebNFS,” doc-umented by Sun in 1996, attempted to showthe performance advantages of a network filesystem for Internet file traffic in some work-loads (over HTTP). The discussion of Web-NFS increased the pressure on other networkfile systems to perform better over the Inter-net, and may have been a factor in the renam-ing of the SMB protocol—from “Server Mes-sage Block” to “Common Internet File Sys-tem.” Related to the work on NFS version4 was an improvement to the SunRPC layerthat NFS uses to transport its PDUs. The im-proved RPCSECGSS allowed support for Ker-beros for authentication (as does CIFS), andallows negotiation of security features includ-ing whether to sign (for data integrity) or seal(for data privacy) all NFS traffic from a par-ticular client to a particular server. The NFSworking group is developing additional exten-sions to NFS (NFS version 4.1, pNFS, NFSover RDMA, and improvements to NFS’s sup-port for a global namespace).

The following shows new protocol operationsintroduced by NFS protocol versions 3 and 4:

NFS VERSION 2 Operations:

• GETATTR 1

• SETATTR 2

• ROOT 3

• LOOKUP 4

• READLINK 5

• WRITE 8

• CREATE 9

• REMOVE 10

• RENAME 11

• LINK 12

• SYMLINK 13

• MKDIR 14

• RMDIR 15

• READDIR 16

• STATFS 17

New NFS VERSION 3 Operations:

• ACCESS 4

• READ 6

• MKNOD 11

• READDIRPLUS 17

• FSSTAT 18

• FSINFO 19

• PATHCONF 20

• COMMIT 21

New NFS Version 4 Operations

• CLOSE 4

5

• DELEGPURGE 7

• DELEGRETURN 8

• GETFH 10

• LOCK 12

• LOCKT 13

• LOCKU 14

• LOOKUPP 16

• NVERIFY 17

• OPEN 18

• OPENATTR 19

• OPEN-CONFIRM 20

• OPEN-DOWNGRADE 21

• PUTFH 22

• PUTPUBFH 23

• PUTROOTFH 24

• RENEW 30

• RESTOREFH 31

• SAVEFH 32

• SECINFO 33

• SETATTR 34

• SETCLIENTID 35

• SETCLIENTID-CONFIRM 36

• VERIFY 37

• RELEASE-LOCKOWNER 39

3 Current Network File System Al-ternatives

Today there are a variety of network file sys-tems included in the Linux kernel, whichsupport various protocols including: NFS,SMB/CIFS, NCP, AFS, and Plan9. In addi-tion there are two cluster file systems now inthe mainline Linux kernel, OCFS2 and GFS2,and a few popular kernel cluster file systemsfor Linux that are not in mainline (includingLustre and IBM’s GPFS). The cifs and nfs filesystem clients for Linux are surprisingly sim-ilar in size (between 20 and 30 thousand linesof code) and change rate. The most commonSMB/CIFS server for Linux is Samba, which issignificantly larger than the Linux NFS serverin size and scope. The most common LinuxNFS server is of course nfsd, implemented sub-stantially in kernel.

Windows Vista also includes support for var-ious network file system protocols includingSMB/CIFS, SMB2 and NFS.

4 SMB2 Under the Hood

The SMB2 protocol differs[7] from the SMBand CIFS protocols in the following ways:

• The SMB header is expanded to 64 bytes,and better aligned. This allows for in-creased limits on the number of active con-nections (uid and tids) as well as the num-ber of process ids (pids).

• The SMB header signature string is nolonger 0xFF followed by “SMB” butrather 0xFE and then “SMB.” In the early1990s, LANtastic did a similar change insignature string (in that case from “SMB”to “SNB”) to distinguish their requestsfrom SMB requests.

6

• Most operations are handle based, leav-ing Create (Open/Create/OpenDirectory)as the only path based operation.

• Many redundant and/or obsolete com-mands have been eliminated.

• The file handle has been increased to 64bits.

• Better support for symlinks has beenadded. Windows Services for Unix did nothave native support for symlinks, but em-ulated them.

• Various improvements to DFS and othermiscellaneous areas of the protocol thatwill become usable when new servers areavailable.

• “Durable file handles”[10] allowing easierreconnection after temporary network fail-ure.

• Larger maximum operation sizes, andimproved compound operation (“AndX”)support also have been claimed but notproved.

Currently 19 SMB2 commands are known:

• 0x00 NegotiateProtocol

• 0x01 SessionSetupAndX

• 0x02 SessionLogoff

• 0x03 TreeConnect

• 0x04 TreeDisconnect

• 0x05 Create

• 0x06 Close

• 0x07 Flush

• 0x08 Read

• 0x09 Write

• 0x0A Lock

• 0x0B Ioctl

• 0x0C Cancel

• 0x0D KeepAlive

• 0x0E Find

• 0x0F Notify

• 0x10 GetInfo

• 0x11 SetInfo

• 0x12 Break

Many of the infolevels used by the Get-Info/SetInfo commands will be familiar tothose who have worked with CIFS.

5 POSIX Conformance

5.1 NFS

NFS version 3 defined 21 network file sys-tem operations (four more than NFS version 2)roughly corresponding to common VFS (Vir-tual File System) entry points that Unix-like op-erating systems require. NFS versions 2 and3 were intended to be idempotent (stateless),and thus had difficulty preserving POSIX se-mantics. With the addition of a stateful lockdaemon, an NFS version 3 client could achievebetter application compatibility, but still can be-have differently[6] than local file systems in atleast four areas:

• Rename of an open file. For example, the“silly rename” approach often used by nfsclients for renaming open files could causerm -rf to fail.

7

• Deleting an existing file or directory canappear to fail (as if the file were notpresent) if the request is retransmitted.

• Byte range lock security (Since these ser-vices are distinct from the nfs server, bothlockd and statd have had problems in thisarea).

• write semantics (when caching was doneon the client).

NFS also required additional protocol exten-sions to be able to support POSIX ACLs,and also lacked support for xattrs (OS/2EAs), creation time (birth time), nanosecondtimestamps, and certain file flags (immutable,append-only etc.). Confusingly, the NFS proto-col lacked a file open and close operation untilNFS version 4, and thus could only implementa weak cache consistency model.

5.2 NFSv4

NFS version 4, borrowing ideas from otherprotocols including CIFS, added support foran open and close operation, became stateful,added support for a rich ACL model similarto NTFS/CIFS ACLs, and added support forsafe caching and a wide variety of extendedattributes (additional file metadata). It is pos-sible for an NFS version 4 implementation toachieve better application compatibility thanbefore without necessarily sacrificing perfor-mance.

5.3 CIFS

The CIFS protocol can be used by a POSIXcompliant operating system for most opera-tions, but compensations are needed in orderto properly handle POSIX locks, special files,

and in order to approximate reasonable val-ues for the mode and owner fields. There areother problematic operations that, although notstrictly speaking POSIX issues, are importantfor a network file system in order to achievetrue local remote transparency. They includesymlink, statfs, POSIX ACL operations, xat-trs, directory change notification (including in-otify) and some commonly used ioctls (for ex-ample those used for the lsattr and chattr util-ities). Without protocol extensions, the CIFSprotocol can adequately be used for most im-portant operations but differences are visible asseen in figure 1.

5.4 CIFS with Unix Protocol Extensions

As can be seen in figure 2, with the CIFS UnixExtensions it is possible to more accurately em-ulate local semantics for complex applicationssuch as a Linux desktop.

The Unix Extensions to the CIFS Protocolhave been improved in stages. An initialset, which included various new infolevels toTRANSACT2 commands in the range from0x200 to 0x2FF (inclusive), was available whenCAP_UNIX was included among the capabili-ties returned by the SMB negotiate protocol re-sponse.

Additional POSIX extensions are negotiatedvia a get and set capabilities request on the treeconnection via a Unix QueryFSInfo and SetFS-Info level. Following is a list of the capabiltiesthat may be negotiated currently:

• CIFS_UNIX_FCNTL_LOCKS_CAP

• CIFS_UNIX_POSIX_ACLS_CAP

• CIFS_UNIX_XATTR_CAP

• CIFS_UNIX_EXATTR_CAP

8

Figure 1: Without extensions to CIFS, local (upper window) vs. remote (below) transparencyproblems are easily visible

• CIFS_UNIX_POSIX_PATHNAMES_CAP(all except slash supported in pathnames)

• CIFS_UNIX_POSIX_PATH_OPS_CAP

A range of information levels above 0x200has been reserved by Microsoft and the SNIACIFS Working Group for Unix Extensions.These include Query/SetFileInformation andQuery/SetPathInformation levels:

• QUERY_FILE_UNIX_BASIC 0x200Part of the initial Unix Extensions

• QUERY_FILE_UNIX_LINK 0x201 Partof the initial Unix Extensions

• QUERY_POSIX_ACL 0x204 RequiresCIFS_UNIX_POSIX_ACL_CAP

• QUERY_XATTR 0x205 RequiresCIFS_UNIX_XATTR_CAP

• QUERY_ATTR_FLAGS 0x206 RequiresCIFS_UNIX_EXTATTR_CAP

• QUERY_POSIX_PERMISSION 0x207

• QUERY_POSIX_LOCK 0x208 RequiresCIFS_UNIX_FCNTL_CAP

• SMB_POSIX_PATH_OPEN0x209 RequiresCIFS_UNIX_POSIX_PATH_OPS_CAP

• SMB_POSIX_PATH_UNLINK0x20a RequiresCIFS_UNIX_POSIX_PATH_OPS_CAP

• SMB_QUERY_FILE_UNIX_INFO20x20b RequiresCIFS_UNIX_EXTATTR_CAP

Currently the CIFS Unix Exten-sions also include the followingQuery/SetFileSystemInformation levelsthat allow retrieving information about aparticular mounted export (“tree connection”),and negotiating optional capabilities. Note thatunlike NFS and SMB/CIFS, the CIFS UnixExtensions allow different capabilities to be

9

Figure 2: Better local (upper window) vs. remote (below) transparency with CIFS Unix extensions

negotiated in a more granular fashion, by “treeconnection” rather than by server session.

If a server is exporting resources located on twovery different file systems, this can be helpful.

• SMB_QUERY_CIFS_UNIX_INFO0x200 (Part of the original Unix Exten-sions)

• SMB_QUERY_POSIX_FS_INFO 0x201

• SMB_QUERY_POSIX_WHO_AM_I0x202

These Unix Extensions allow a CIFS clientto set and return fields such as uid, gidand mode, which otherwise have to be ap-proximated based on CIFS ACLs, and alsoto drastically reduce the number of networkroundtrips, the number of operations requiredfor common path based operations. For ex-ample, with the older CIFS Unix Extensions,a file create operation takes many network

operations: QueryPathInfo, NTCreateX, Set-PathInfo, QueryPathInfo in order to implementlocal Unix create semantics correctly. File cre-ation can be done in one network roundtipusing the new SMB_POSIX_PATH_OPEN,which reduces latency and allows the serverto better optimize. The improved atomicity ofmkdir and create makes error handling easier(e.g., in case a server failed after a create oper-ation, but before the SetPathInfo).

5.5 SMB2

The SMB2 protocol does improve upon its pre-decessors in including symlink support, butretrieving mode and Unix uid and gid fromNTFS/CIFS ACLs is awkward, and SMB2 ap-pears only slightly improved in this area, andsubstantially worse than the CIFS Unix Exten-sions for this purpose.

10

octet 1 2 3 4 5 6 7 8

RFC 1001 msg type (session)

SMB length (some reserve top 7 bits) 0xFF 'S' 'M' 'B'

SMB Command

Status (error) code SMB flags SMB flags2

Process ID (high order) SMB Signature

SMB signature (continued) Reserved Tree Identifier Process Id (Low)

SMB User Identifier Word Count (variable number of 16 bit parameters follow)

Byte Count (size of data area) (data area follows)

Table 1: SMB Header Format (39 bytes + size of command specific wct area)

octet 1 2 3 4 5 6 7 8

RFC 1001 msg type (session)

SMB length 0xFE 'S' 'M' 'B'

SMB Header length (64) reserved Status (error) code

SMB2 Command Unknown SMB2 Flags

Reserved Sequence number

Sequence Number (continued) Process Id

Tree Identifier SMB User Identifier

SMB User Identifier SMB Signature

SMB Signature (continued)

SMB Signature (continued) SMB2 Parameter length (in bytes)

Variable length SMB Parm

Variable length SMB Data

Table 2: SMB2 Header Format (usually 68 bytes + size of command specific parameter area)

octet 1 2 3 4 5 6 7 8

SunRPC Fragment Header XID

Message Type (Request vs. Response) SunRPC Version

Program: NFS (100003) Program Version (e.g. 3)

NFS Command Authentication Flavor (e.g. AUTH_UNIX)

Credential Length Credential Stamp

Machine Name length Machine name (variable size)

Machine Name (continued, variable length)

Unix UID Unix GID

Auxiliary GIDs (can be much larger)

Verifier Flavor Verifier Length

NFS Command Parameters and/or Data follow

Table 3: SunRPC/NFSv3 request header format (usually more than 72 bytes + size of nfs command)

11

6 Performance

CIFS has often been described as a “chatty”protocol, implying that it is inherently slowerthan NFS, but this is misleading. Most chatti-ness in observed behavior of CIFS is the resultof differences between the operating systemimplementations being compared (e.g., Win-dows vs. Linux). Another factor that leadsto the accusation of the CIFS protocol being“chatty” (wasteful of network bandwidth) isdue to periodic broadcast frames that containserver announcements (mostly in support of theWindows Network Neighborhood). These arenot a required part of CIFS, but are commonlyenabled on Windows servers so that clientsand/or “Browse Masters” contain current listsof the active servers in a resource domain.

There are differences between these proto-cols that could significantly affect performancethough, and these include: compound opera-tions, maximum read and write sizes, maxi-mum number of concurrent operations, endiantransformations, packet size, field alignment,difficult to handle operations, incomplete oper-ations that require expensive compensations.

To contrast features that would affect perfor-mance it is helpful to look at some examples.

6.1 Opening an existing file

The SMB2 implementation needs a surprisingeight requests to handle this simple operation.

6.2 Creating a new file

The SMB2 protocol appears to match perfectlythe requirements of the Windows client here.Attempting a simple operation like:echo new file data > newfile

results in the minimum number of requeststhat would reasonably be expected (opencre-ate, write, close). Three requests and three re-sponses (823 bytes total).

6.3 Mount (NET USE)

Once again the SMB2 protocol appears tomatch well the requirement of the client withonly 11 requests (four are caused by the Win-dows desktop trying to open Desktop.iniand AutoRun.inf).

7 Linux Implementation

Much of the progress on SMB2 has been dueto excellent work by the Samba 4 team, ledby Dr. Andrew Tridgell. Over the past yearand a half, they have implemented a compre-hensive client library for SMB2, implementeda test suite (not as comprehensive yet), im-plemented DCE/RPC over SMB2 (for remoteadministration), implemented a SMB2 server(not complete), and in cooperation with RonnieSahlberg, implemented a wireshark (ethereal)protocol analyzer.

8 Future Work and Conclusions

Although great progress has been made on aprototype user space client in Samba 4, an im-plementation of SMB2 in kernel on Linux alsoneeds to be completed, and we have begun aprototype. The SMB2 protocol represents amodest improvement over the older SMB/CIFSprotocol, and should be slightly better despitethe slightly larger frame size caused by thelarger header. With fewer commands to op-timize and better aligned fields, performance

12

may be slightly improved as server developersbetter tune their SMB2 implementations.

Despite the addition of support for symlinks,the SMB2 protocol lacks sufficient support forfeatures needed by Unix and Linux clients.Adding Unix extensions to SMB2, similar towhat has been done with CIFS, would be pos-sible and could reuse some of the existing Unixspecific infolevels.

With current Linux kernels, NFS version 4and CIFS (cifs client/Samba server) are goodchoices for network file systems for Linux toLinux. NFS performance for large file copyworkloads is better, and NFS offers some secu-rity options that the Linux cifs client does not,but in heterogeneous environments that includeWindows clients and servers, Samba is oftenmuch easier to configure.

9 Acknowledgements

The author would like to express his apprecia-tion to the Samba team, members of the SNIACIFS technical work group, and others in an-alyzing and documenting the SMB/CIFS pro-tocol and related protocols so well over theyears. This is no easy task. In addition, thanksto the Wireshark team and Tridge for helpingthe world understand the SMB2 protocol bet-ter, and of course thanks to the Linux NFSv4developers and the NFS RFC authors, for im-plementing and documenting such a complexprotocol. Thanks to Dr. Mark French for point-ing out some of the many grammar errors thatslipped through.

10 Legal Statement

This work represents the view of the author and doesnot necessarily represent the view of IBM. IBM,

OS/2, GPFS, and OS/400 are registered trademarksof International Business Machines Corporation inthe United States and/or other countries. Microsoft,Windows and Windows Vista are either a registeredtrademark or trademark of Microsoft Corporation inthe United States and/or other countries. UNIX isa registered trademark of The Open Group in theUnited States and other countries. POSIX is a reg-istered trademark of The IEEE in the United Statesand other countries. Linux is a registered trademarkof Linus Torvalds. Other company, product and ser-vice names may be trademarks or service marks ofothers.

References

[1] Sun Microsystems Inc. RFC 1094: NFS:Network File System ProtocolSpecification. March 1989. See http://www.ietf.org/rfc/rfc1094.txt

[2] Callaghan et al. RFC 1813: NFS Version 3Protocol Specification. June 1995. Seehttp://www.ietf.org/rfc/rfc1813.txt

[3] S. Shepler, et al. RFC 3530: Network FileSystem (NFS) version 4 Protocol. April2003. See http://www.ietf.org/rfc/rfc3530.txt

[4] J. Norton, et al. SNIA CIFS TechnicalReference. March 2002. Seehttp://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf

[5] C. Hertel. Implementing CIFS. 2004. Seehttp://ubiqx.org/cifs/

[6] O. Kirch. Why NFS Sucks. Proceedings ofthe 2006 Ottawa Linux Symposium,Ottawa, Canada, July 2006.

13

[7] Dr. A. Tridgell. Exploring the SMB2Protocol. SNIA Storage DeveloperConference. September 2006. http://samba.org/~tridge/smb2.pdf

[8] CIFS Unix Extensions.http://wiki.samba.org/index.php/UNIX_Extensions

[9] Linux CIFS Client and Documentation.http://linux-cifs.samba.org

[10] What’s new in SMB in Windows Vistahttp://blogs.msdn.com/chkdsk/archive/2006/03/10/548787.aspx

14