17.2 Distributed File System (DFS)

The CIFS D istributed F ile S ystem (DFS) is not nearly as fancy as it sounds. It is simply a way to collect separate shares into a single, virtual tree structure. It also has some limited ability to provide fileserver redundancy and load balancing.

The key feature of DFS is that it can create links from within a shared tree on one server to shares and directories on another, thus providing a single point of entry to a virtual SMB tree. From the user 's perspective, the whole thing looks like a single share, even though the resources are scattered across separate SMB servers.

Clear as mud? Perhaps an illustration will help...

In Figure 17.1, the client is shown attempting to access a file on server PETSERVER . Well, that's where the client thinks the file resides. On the server side, the name CORGIS in the DOGS directory is actually a link to another UNC pathname, \\DATADOG\CORGIS . Following that link leads us to a different share on a different server.

Figure 17.1. Distributed File System

The client is using an SMB URL to access an image of a Pembrokeshire Welsh Corgi playing in the snow. The URL is translated into UNC format for use with the SMB protocol. The server traverses the UNC path until it reaches corgis , which is a link to a share on a different server.

 CORGIS ==> \DATADOG\CORGIS 

The client is redirected to the new server, where it finally finds the file it wanted.

The server offering the DFS share ( PETSERVER , in our example) does not act as a proxy for the client. That is, it won't follow the DFS links itself. Instead, the server sends an error code to the client indicating that there is some additional work to be done. The error code is either a DOS code of ERRSRV/ERRbadtype ( 0x02/0x0003 ), or an NT_STATUS code of STATUS_DFS_PATH_NOT_COVERED ( 0xC0000257 ).

The client's task, at this point, is to query the server to resolve the link. The client sends a TRANS2_GET_DFS_REFERRAL which is passed to the server via the Trans2 transaction mechanism, briefly described earlier. The client will use the information provided in the query response to create a new UNC path. It must then establish an SMB session with the new server. This whole mess is known as a "DFS referral."

It was mentioned above that DFS can provide a certain amount of redundancy. This is possible because the links in the DFS tree may contain multiple references. If the client fails to connect to the first server listed in the referral it can try the second, and so on. DFS can also provide a simple form of load balancing by reshuffling the order in which the list of links is presented each time it is queried. Of course, load balancing and redundancy are only workable if all of the linked copies are in sync.

A quick search on the web will turn up a lot of articles and papers that do a better job of describing the behavior of DFS that the blurb provided here. If you are planning on implementing DFS, it is worthwhile to read up on the subject a bit, just to get a complete sense of how it is supposed to work from the user or network administrator's perspective. The SNIA doc provides enough information to get you started building a working client implementation. The server side is more complex because doing it right involves implementing a set of management functions as well.