Windows File Systems - CIFS

Introduction

The Common Internet File System (CIFS) was developed in response to changes in the way people are using the Internet. The Internet is basically a read-only environment, and access is managed using one-way protocols like HTTP and FTP. However the Internet is becoming more interactive so a new read/write interface is needed, and that is what CIFS is all about. CIFS is designed to enable all applications, not just Web browsers, to open and share files securely across the Internet.

CIFS is based on Microsoft’s open Server Message Block (SMB) protocol, which is widely in use by personal computers and supported by a wide variety of operating systems. CIFS runs over TCP/IP and complements HTTP, it does not replace it. It also provides a more sophisticated file sharing and file transfer than older protocols such as FTP.

Now there is an awful lot of information and lots of big words and TLAs (Three Letter Acronyms) out there about CIFS. In simple terms, a remote file system needs to be able to

• Find files located on various servers and drives
• Keep the various interested parties informed about what’s happening to files, and be able to speak the variety of languages used by different operating systems
• Only let authorised people access files
• Let people share files without corrupting them
• Handle a variety of network situations, including slow speeds and lost links
• Support the usual set of file operations: open, close, read, write, and seek.

Finding files

CIFS needs two pieces of information to locate a file. It needs the server name, then the path name to the file on the server.
The server can be identified by a URL file://fs.lascon.co.uk/, by an IP address, 192.123.932.12 or by the UNC name.
The client resolves this to a transport address using DNS (Domain Naming Service) or possibly NetBIOS.

File names can be in any character set, not just character sets designed for English or Western European languages. Users can refer to remote file systems directly with 'globally significant' names; they do not have to mount them.

CIFS can use DFS, which allows users to construct an enterprise-wide namespace. The path name should always have the full file name, including the server name and share name. If the server can resolve the DFS name to local storage, the local storage will be accessed.

Messaging

Before two machines can start communicating they must negotiate the dialect of CIFS to use. Different dialects can include both new messages as well as changes to the fields and semantics of existing messages in other dialects.

CIFS uses commands to pass information between networked computers. The type of information passed includes starting and ending a connection to a shared resource, namespace messages to gain access to files at the server and file manipulation messages to read and write them, and printer messages send data to a print queue at a server and to get status information about the print queue.

Integrity and Concurrency

CIFS allows local caching of remote files for speed, and to reduce network traffic. CIFS also allows multiple clients to access a file simultaneously. If a file is updated by another process, then the local cached version is invalid. If two or more processes update a file concurrently, the data may be corrupted. CIFS uses ‘opportunistic’ file locks, or oplocks to avoid these problems.
Applications can register with a server to be notified if and when file or directory contents are modified. They can use this to (for example) know when a display needs to be refreshed, without having to constantly poll the server.

There are three different types of oplocks -

‘exclusive oplock’

means that a single client owns a file, and no other client can share it, not even for read. The owning client can use read-ahead and write-behind buffers safely, as there will be no conflict with other clients. The exclusive lock is released when the client closes the file. If a second client requests access, the owning client must write out any buffered updates before the exclusive oplock is freed.

'batch oplock’

allows a client to keep a file locked on the server after it has closed the file. This is useful when an application knows it is going to open the file again and does not want to impose a load on the Network by flushing cache, reloading data and requesting another lock.

‘Level II oplock’

allows multiple readers to share a file, but no writers. If a client has a Level II oplock, then it cannot contain information about the lock in a local cache. It must go to the remote server to see if the shared lock condition still exists.

You can control and change how Windows uses Oplocks by altering the Registry. Make sure you back up the Registry and are prepared for system failure before you start changing Registry values.

The UseOpportunisticLocking parameter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters determines whether the client uses Oplocks or not. Valid values are 0 (false) or 1 (true), the default is 1.

The Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters contains a few relevant Oplocks parameters –

• The EnableOplocks parameter determines whether the server lets clients use Oplocks on files. Valid values are 0 (false) or 1 (true), the default is 1.
• The MinLinkThroughput parameter determines the minimum link throughput the server allows before it disables raw I/O and Oplocks for this connection. Valid values are 0 bytes per second (bps) to infinite bps, the default is 0.
• The MaxLinkDelay parameter determines the maximum time allowed for a link delay. If delays exceed the value you specify for this setting, the server disables raw I/O and Oplocks for this connection. Valid values are 0 seconds to 100,000 seconds, and the default is 60.
• The OplockBreakWait parameter determines the amount of time the server waits for a client to respond to an Oplock break request. Using a small value for this setting lets the server detect crashed clients quickly but can cause you to lose cached data. Valid values are 0 seconds to 180 seconds, the default is 35.

Optimization for Slow Links

The CIFS protocol is tuned for improved performance over slow-speed dial-up lines. Local caching also helps users who access the Internet using a modem. This is discussed a bit in the Integrity section above, but basically read-ahead caching will load up records to the local cache before they are required, and write-behind caching writes out to the local cache for downloading to the remote server at a later time.

The CIFS protocol is perceived to be a bit 'chatty' and this can cause time delays when accessing servers over networks. CIFS can issue over one thousand messages just to access a Word file, and that can add up to 90 seconds to the time it takes to open the file.

Security

CIFS servers support both anonymous transfers and secure, authenticated access to named files. File and directory security policies are easy to administer.

Distributed Replicated Virtual Volumes

CIFS supports file subtrees that can span multiple volumes and servers. Its possible to physically move files and directories to a different server without changing the names. Its also possible to replicate subtrees to spread performance load, or provide fault tolerance.

back to top

By entering and using this site, you accept the conditions and limitations of use