Technical Overview of Dfs

Dfs Concepts, Terms, and Conventions

What is a Dfs Root?

A Dfs Root is a local share which serves as the starting point and host to other shares. Any shared resource can be published into the Dfs namespace.

Accessing a Dfs Volume

A Dfs volume is accessed using a standard UNC name:

\\Server_Name\Dfs_Share_Name\path\file

where Server_Name is the name of the hosting Dfs machine name, Dfs_Share_Name maps to any share you've designated to be the root of your Dfs, and path\file is any valid Win32® pathname. One can net use a drive to any place in the Dfs. Dfs provides a level of indirection between such a UNC name and the underlying server and share which is actually hosting the file or directory.

Shares participating in a Dfs may be hosted by any server accessible by clients of the Dfs. This includes shares from the local host, shares on any Windows NT server or workstation, or shares accessible to Windows NT through client software (e.g., NetWare, Banyan, etc.).

Additionally, with the Directory Service enabled version of Dfs, a Dfs volume can be accessed by both its fault tolerant name and its domain name:

    \\Fault_Tolerant_Name\Dfs_Share_Name\path\file
    \\Domain_Name\Fault_Tolerant_Name \path\file

where Fault_Tolerant_Name is a name selected by an administrator to specify a Dfs volume stored in the DS (this may be a group of machines providing root level fault tolerance) and \\Domain_Name\Volume is the name of a standard volume object in Windows NT Directory Services.

Hosting a Dfs Volume

A network can host many individual Dfs volumes, each having a distinct name. Any Windows NT 4.0 server, or greater, can run the Dfs service and host a Dfs volume. For the Windows NT 4.0 release of Dfs, a server can host one and only one Dfs. There are no architectural limits which prevent the Windows NT operating system from hosting multiple Dfs volumes in future releases.

A typical Dfs scenario would have a Dfs volume composed of link volumes from multiple servers throughout an organization. For example, consider an organization in the banking industry that has a pool of workers who handle word processing needs. This pool of workers would need access to documents stored in every department and branch throughout the organization. A single Dfs volume hosted locally could tie together only those servers and the specific share points which are typically used to store word processing information. The following table shows a typical Dfs.

A hierarchical diagram of the table above would look like the following:

Figure 4: Typical Dfs

In addition to representing the table of junctions(table above), there are three important examples presented in Figure 4. They are:

• post-junction junctions
• alternate volumes
• downlevel volumes

These are described in detail below.

Post-junction Junctions

This is a junction which in turn has children junctions. There are two methods of setting this up: Inter-Dfs Links and Mid-Level Junctions.

Inter-Dfs Links (Stand-Alone Server)

It is possible to junction from one Dfs volume to another Dfs volume. As an example, individual departments within an organization may choose to set up and administer a logical namespace that matches their work needs. The corporate Dfs volume could link together all departmental Dfs volumes. The effect of an Inter-Dfs link is that as you cross the junction, you have in effect changed the server you reference as your Dfs root. Although this is transparent to the end user, the Dfs client now receives its referrals from the new Dfs root.

Mid-Level Junctions (Directory Service enabled version only)

This is a planned feature for a future release of Dfs to support unlimited hierachical junctioning that does not require Inter-Dfs links. All referrals will be resolved from the original Dfs root, which reduces points of failures and minimizes the number of referrals required to resolve deeply nested paths.

Alternate Volumes

If two (or more) shares in an organization are effectively exact replicas of one share, and you wish to leverage the volumes, you can mount them at a single point in your Dfs namespace.

Dfs makes no attempt to ensure that the data stored between the two shares is replicated. Dfs replicas should be considered alternative sources of otherwise synchronized or replicated data (either manually or automatic). Until content replication is present, alternate volumes are most likely beneficial in a read-only scenario where any data writes are performed through physical naming across all alternates.

Dfs has a limit of 32 alternates for any given junction point in Dfs (there is no limit to the number of junctions created at any point in your Dfs tree).

Downlevel Volumes

Any volume that is Windows NT Server 4.0 or greater can host a Dfs volume and participate as an Inter-Dfs Link. All other volumes are considered downlevel. Downlevel volumes can be published in the Dfs volume, but can not themselves host Dfs or junction to other volumes. This includes Windows NT Workstation (all versions), Windows 95, Windows for Workgroups, and all non-Microsoft shares for which client redirectors are available. It is important to note that Windows 95 Dfs-aware client can take referrals for all uplevel volumes and all SMB (Microsoft) downlevel volumes, but can not negotiate non-SMB volumes.

Partition Knowledge Table

The partition knowledge holds knowledge of all junction points. It is administered by the Dfs Admin API shown in Appendix 1.

Figure 5: Partition Knowledge Table

As shown in Figure 5, the Partition Knowledge Table maps the Logical Dfs namespace into physical referrals (alternate volumes appear as a list for a single junction).

When the Dfs client attempts to navigate a junction, it first looks to its locally cache PKT entries. If the referral cannot be resolved, the client contacts the Dfs root. If the referral can still not be resolved, an error will occur. If the referral is properly resolved, the client adds the referral to its local table of entries.

When a Dfs client obtains a referral from the PKT, that referral is cached for 5 minutes. If the client re-uses that referral, then the time-to-live is renewed; otherwise the cache expires. If alternate volumes exist for a particular referral, then all alternates are handed to and cached by the client. The client randomly selects which referral to use.

Dfs Referrals: How Junctions Are Resolved from Logical Names into Physical Addresses

The Dfs aware redirector, SMB server, and Dfs driver collaborate to reroute path-based operations to the actual server/share hosting the file or directory. There are two new transaction SMBs defined for this, seven public administrative APIs, and ten private APIs. These are covered in Appendix 2.

With a stand-alone Dfs volume, the referral process will never extend more than one level deep before encountering either a leaf (a point which cannot junction, such as a downlevel volume), or an Inter-Dfs link. Upon encountering an Inter-Dfs link, the referral process begins over on the flip side of the junction to resolve referrals deeper in the logical namespace.

The Directory Service Enabled version of Dfs will permit junctions to junctions (without requiring inter-Dfs links). In this scenario, it is important to note that the referral process expressly searches for the LONGEST (most "\" characters) referral that can be resolved from the requested path. This assures that with a single referral, the final destination will have been resolved.

Figure 6: Trans2_Dfs_Get_Referral process

In the Figure 6, the directories \Scratch and \My_Tree are meant to represent junctions to other servers (for Windows NT 4.0, this is not possible without Inter-Dfs links, and in this case, two referral operations would be required rather than just one).

Failover Between Alternates Volumes

As outlined in the above two sections, referrals are cached locally for performance considerations and when alternates are available, all alternates are provided to the client. The client arbitrarily chooses which referral to use (in the directory-enabled version of Dfs, this will be based on sites to ensure that clients select available alternates within their site).

Once a referral is selected among the alternates, a session setup is performed (credentials are passed to the new server if a prior connection does not exist). Should the selected referral fail, a failover process will begin. The speed and implications of the failover are dependent on what the client was doing at the time of the failure and how the failure occurred.

Scenario #1

A client is browsing an alternate volume. The machine hosting the alternate loses power or drops completely from the network for any reason. In order to failover, the client must first detect that the hosting machine is no longer present. How long this takes is dependent which the protocol the client is using. Many protocols account for slow and loosely connected WAN links, and as such may have retry counts to upwards of two minutes before the protocol itself times out. Once that occurs, Dfs will immediately select a new alternate. If none are available from the local cache, the Dfs client will consult with the Dfs root to see if the administrator has modified any PKT entries. If no alternates are available at the root, a failure will occur; otherwise Dfs will initiate a fresh alternate selection and session setup.

Scenario #2

A client is browsing an alternate volume The machine hosting the alternate loses a hard disk hosting the alternate, or the share is deactivated. In this scenario, the server hosting the Alternate is still responding to the client request; the failover to a fresh Alternate is nearly instantaneous.

Scenario #3

A client has open files. The machine hosting the alternate loses power or drops completely from the network for any reason. In this scenario, you will have the same protocol failover process described in Scenario #1. Also, it is dependent on the application which previously had file locks from the previous alternate to detect the change and establish new locks.

New attempts to open files will trigger the same failover process described in Scenario #1. Operations on already open files will fail with appropriate errors.

Scenario #4

A client has open files. The machine hosting the alternate loses a hard disk hosting the alternate, or the share is deactivated. In this scenario, you will have the same very quick failover process described in Scenario #2. Also, it is dependent on the application which previously had file handles from the previous alternate to detect the change and establish new handles .

Security

Session Setups

As each junction is crossed and cached for the first time, the Dfs aware client establishes a session setup with the server on the flip side of the junction. The credentials the user originally used to connect with Dfs are used (e.g., Net Use * \\Server\Dfs_Share /u:domain\user). If the user did not supply credentials, then the credentials cached when the user logged into their workstation will be used.

ACLs

File ACLs are administered at each individual physical share. There is no mechanism to administrate ACLs system-wide from the Dfs root, nor is there an attempt to keep ACLs consistent between alternate volumes. There are several reasons for this:

• A centrally administrated logical ACL database could be bypassed, as users could directly Net Use to the physical resource.
• The logical Dfs volume can cross between FAT and NTFS volumes, as well as contain leaves from other network operating systems. There is no reasonable way to set an inherited Deny ACL which starts on a NTFS volume, passes to FAT, passes back to NTFS, and concludes on NetWare volume.
• A tool which walks the logical namespace appropriately setting ACLs would require a complicated message and transactioning engine to ensure that ACLs would be queued and updated over loosely connected and/or unreliable networks.
• Storage quotas available in 5.0 would require an additional burden of tallying storage for all possible users across all possible volumes to establish when users have exceeded their storage allotment.

Figure 7: Block Architecture showing various binary components

Additionally, a utility called DfsCMD.EXE permits your Dfs structure to be modified with scripting commands.

Considerations for Developers Writing Applications which Leverage Dfs

Free Space

When enumerating the available storage space on a volume, GetDiskFreeSpace will return the space available at the root of the Dfs volume. It does not walk the tree summing up the space available across assorted junctions. GetDiskFreeSpaceEX is a new function to return the space available at a specified point within a namespace, which permits you to obtain the free space on the flip side of a junction. This result will be dependent if alternate volumes are mounted and if alternates have identical storage devices.

Connections

As Dfs permits workstations and servers to participate equally as junction points, it should also be noted that a Windows NT workstation only permits ten clients to connect to it. This means that a share on a Windows NT workstation published in Dfs cannot be accessed once ten connections have been established to that workstation (whether those connections are utilizing the private Dfs or not). Stand-alone servers do not have this limitation. It should be noted that only Windows NT Server can host a Dfs root, but any share or volume accessible via the network can participate in the Dfs namespace.

File Systems

Dfs is always hosted on Windows NT Server 4.0 or greater. This can be either FAT or NTFS format. As junctions are crossed, you may change from one file format to another. Also, with downlevel volumes, you may change from Windows NT to an alternate NOS which is both formatted uniquely and has a different security model. Another effect of junction to different physical servers is that the network address between logical sub-directories may change (this is transparent to end users and applications).

Backup and Restore

With Dfs, a volume can be built to encompass all storage on your network. The net effect is that through a single namespace, all storage can be backed up. It is important that your backup solution be aware of your Dfs topology. For example, if you wish to restore a portion of your logical namespace when those physical servers no longer exist, it is important that you can identify that fact and be prompted with intelligent suggestions as to what to do with the data (e.g., queue the restore on the assumption the server is temporarily down, move the contents to another location and automatically re-configure the logical namespace, or cancel the operation).