DFS Scalability in Windows NT 4.0 and Windows 2000

ID: Q232613

The information in this article applies to:

Microsoft Windows 2000 Advanced Server
Microsoft Windows 2000 Datacenter Server
Microsoft Windows 2000 Professional
Microsoft Windows 2000 Server

SUMMARY

This article discusses sizing issues for the deployment of the Distributed File System (DFS) service on Microsoft Windows NT 4.0 and Windows 2000 servers.

MORE INFORMATION

DFS 4.1

DFS 4.1 is an add-on component that runs on Windows NT 4.0 Workgroup and Member servers and domain controllers. The DFS components are downloadable from http://www.microsoft.com. The DFS configuration is stored on a per-computer basis in the Windows NT 4.0 registry.

Resource: Maximum number of Fault Tolerant roots supported per domain
Limit: N/A

Resource: Maximum number of stand-alone roots supported per computer
Limit: 1

Resource: Maximum number of volumes in a domain DFS
Limit: N/A

Resource: Maximum number of volumes in a stand-alone root
Limit: 2000 is common, routinely exceeded by Microsoft, 6000 tested by customers

Resource: Maximum number of root replica members
Limit: N/A

Resource: Maximum number of child replica members
Limit: 255

Windows 2000 DFS

Resource: Maximum number of Fault Tolerant roots supported per domain
Limit: 1 per computer, unlimited per domain

Resource: Maximum number of stand-alone roots supported per computer
Limit: 1

Resource: Maximum number of volumes in a domain DFS
Limit: 1000

Resource: Maximum number of volumes in a stand-alone root
Limit: 10,000 tested by DFS test team

Resource: Maximum number of root replica members
Limit: 32

Resource: Maximum number of child replica members
Limit: 256

DFS servers store information about the DFS topology in a structure called the Partition Knowledge Table (PKT). The PKT data structure consists of the DFS directory name and the list of referral servers that DFS clients actually connect to. DFS clients "walk" the locally cached subset of the PKT from the top down when a directory in the DFS name space is used, and return to the DFS root or child replicas when a TTL timer expires, the client is rebooted, or none of the servers in the client's PKT are available.

Once the PKT is cached, the client burden shifts away from the DFS root and child replicas to the referral servers. The scalability question becomes "How many SMB sessions can be supported by the DFS root, child replicas, and referral servers to which DFS clients connect?".

Modification of the the AutoDisconnect value for the Windows NT Server service may be appropriate to balance memory overhead associated with servers maintaining idle sessions and session reestablishment from idle clients reconnecting, depending on how frequently the directory in the DFS name space is used and the time the DFS configuration is cached on the client (the TTL value defined on the server).

Use long AutoDisconnect values for paths consistently used several times per day (such as home directories, or when there is only one physical server). Use shorter AutoDisconnect times for infrequently used data or paths representing installation servers on which file copying or program installations might last 10-60 minutes. Consider the additional roles (such as file & printer sharing, Web server, or program server) the server plays in addition to hosting the DFS root.

A busy DFS server might maintain as many as 3000-6000 sessions. The AutoDisconnect value for such a server can be decreased for DFS servers hosting volumes with long TTL values. For additional information, please see the following article in the Microsoft Knowledge Base:

Q138365 How the AutoDisconnect Works in Windows NT

Additional query words:

Keywords : kbenv kbtool
Version : WINDOWS:2000
Platform : WINDOWS
Issue type : kbinfo