What's in a name? Does CIFS (Common Internet File System) by its other name, SMB, smell as sweet to enterprise Linux shops? Yes and no, says Samba Team member Chris Hertel. CIFS started out as an update of the Server Message Block (SMB) protocol for file, printer, port and communications sharing. "Now, it's now something bigger, better and, if not sweeter, then more palatable," said Hertel, author of Implementing CIFS: The Common Internet...
File System, which is part of Bruce Perens' Open Source Series from Prentice Hall PTR. That said, CIFS does have some Linux limitations. In this interview, Hertel describes the differences between it and SMB, and CIFS' relevance to enterprise Linux environments.
How is CIFS different from SMB?
Hertel: I have heard others call CIFS a 'marketing upgrade.' Basically, CIFS is a newer name for SMB, coined back in mid-to-late '90s when Microsoft thought it was competing with Sun for the Web file system market (remember WebNFS?). So, in that sense, CIFS is the same as SMB.
In more recent years, however, people have moved toward using the term CIFS to mean the entire protocol suite and all its ancillary propaganda. People use the term SMB when referring to the core file-sharing protocol itself. CIFS is a marketing term, so its meaning is flexible.
Isn't CIFS just for Windows environments?
Hertel: Yes and no. Samba and the various client file system implementations for Linux, BSD and other OSes all demonstrate that CIFS can be made to work in a non-Windows or semi-Windows environment.
The question is a good one, though, because CIFS is in many ways tuned to the Windows environment.
SMB was originally developed for use with DOS (both IBM's PC-DOS and Microsoft's MS-DOS products). I am not personally familiar with the innards of DOS, but I have been told that the original SMB protocol maps very cleanly to DOS file I/O function calls. The extensions and updates made to SMB over the years have closely followed DOS, OS/2 and now Windows feature enhancements.
The problem is that it is sometimes difficult to map between Windows and non-Windows semantics. Consider a simple example: In Windows, the names 'neko,' 'Neko' and 'NEKO' are equivalent because Windows file systems are case insensitive. In contrast, a Unix system would recognize all three of the above as distinct names.
Third-party CIFS developers, including the Samba Team, have had to come up with some interesting tricks to map between the Unix and Windows worlds. Doing so is necessary, however, if these disparate system types are going to live in harmony in the same network neighborhood.
How can IT shops take advantage of the CIFS virtual file system (VFS) for Linux in an enterprise environment?
Hertel: I am really pleased with the attention that [Samba developer] Steve French's work is getting. CIFS VFS is a specific project, and it's mostly Steve's work. He's done a wonderful job of integrating CIFS into Linux, and he deserves a lot of credit.
The VFS layer within Linux makes it very, very easy to add new file systems. That means it is easy to add code that understands CIFS, or NFS, or some obscure experimental system. Many IT shops already have a major investment in CIFS. It is possible to run other file-sharing protocols as well, even from the same server. Novell, Network Appliance and Unix-based servers can all offer NFS in addition to CIFS.
The problem is that not all CIFS installations are strictly client-server. Some have a more peer-to-peer structure. In some cases, it may be impractical to run multiple protocols on the server. In those situations, the CIFS VFS makes it easier to integrate Linux desktops into a CIFS-centric network.
Does CIFS VFS for Linux have any relevance to servers running Linux?
Hertel: The CIFS VFS for Linux is a client. It allows a Linux system to mount a CIFS share and make it look as though it were a local directory. So, on the surface, it would not appear as though CIFS VFS for Linux can do much to help the server.
The thing is, Steve French is a clever guy. He has spent a lot of time distilling out the minimum set of SMB commands necessary to provide a complete, but very slender, CIFS client implementation. By using these calls efficiently, he can streamline the responses required by the server.
Andrew Tridgell, the Samba Team leader, has been studying the behavior of various SMB calls against different servers, and has found some efficiencies there as well. All of this information was exchanged and discussed at the recent CIFS conference (hosted by the Storage Networking Industry Association).
So, there are limitations to the benefits of using CIFS VFS for Linux in an enterprise environment, right?
Hertel: The CIFS VFS for Linux is a client implementation, not a server. It won't offer file shares to other clients.
That said, there are a couple of limitations of which I am aware:
- It runs only on Linux and only on newer versions of the kernel. For some kernels, it has to be added as a patch. Eventually, it will be a standard option.
- It is tuned to work with Samba and with Windows 2000, XP and 2003 servers. It may work with others, or it may not. There is a great deal of variation in CIFS server implementations. It is possible for it to be compatible with almost everything out there, but it requires a lot more work and a lot more code.
For interoperability with older Windows servers, Linux also offers the SMBFS file system, maintained by [kernel maintainer] Urban Widmark.
Why would anyone want to use a shared file system across a network such as a WAN/MAN or the Internet itself?
Hertel: I don't think most people do. WebNFS never really caught on, did it?
Most file sharing is done locally. For long-distance, we use FTP, HTTP and scp (Secure Copy). We copy the remote files to the local environment, fiddle with them, and then send them back.
I have personally been known to use CIFS file sharing over a long distance. For example, at the CIFS conference in California, I remote-mounted shares from my Samba server at home (in Minnesota). I used a VPN tunnel to protect the data and ensure a reliable network link. I did not, however, use files on the mounted system directly. That would have been too slow and, if a network glitch occurred, it might leave a remote file in an awkward state. Instead, I copied the files to my local drive, did my work and then copied them back.
In truth, the work I did probably would have been handled better by a version management system such as CVS. But I was at the CIFS conference, so. ...
Now, imagine a network file system that would handle that kind of remote file sharing for you. It would cache opened files on the local system and resynchronize the file when it detected that it was at a stable state (following a 'flush' or 'close' operation, for instance). Such network file systems do exist. The prototype is Coda, developed at Carnegie Mellon University (CMU). Coda is still an active project, but there are now others with similar goals.
What is it about CIFS that makes it difficult to work with?
Hertel: The original SMB protocol was developed by Dr. Barry Feigenbaum at IBM in the early days of the PC. It was small, simple and clean. Over the years, however, the protocol has been enhanced and extended, and today it is much bigger and much more complex.
Unlike NFS, CIFS is a closed protocol. There are no current standards and no independent compliance tests. Microsoft plays this card close to their collective chest. That makes it difficult for third-party implementers to 'get it right.' Writing CIFS code is a game of trial-and-error. The bigger problem, however, is that there is no peer review. As a result, Microsoft can simply add on new features and use them to enhance the behavior of their products, and the CIFS suite grows without bounds.
FOR MORE INFORMATION: