The staging directory acts as a queue for changes to be replicated to downstream partners. After the changes are made to a file and the file is closed, the file content is compressed, written to the staging directory, and replicated according to schedule. Any further use of that file does not prevent FRS from replicating the staging file to other members. In addition, if the file is replicated to multiple downstream partners or to members with slow data links, using a staging file ensures that the underlying file in the replica tree can still be accessed.
The size of the staging directory governs the maximum amount of disk space that FRS can use to hold those staging files and the maximum file size that FRS can replicate. The default size of the staging directory is approximately 660 MB, the minimum size is 10 MB, and the maximum size is 2 TB. The largest file that FRS can replicate is determined by the staging directory size on both the upstream partner (the replica member that sends out the changed file) and downstream partners (the replica member that receives the changed file) and whether the replicated file, to the extent that it can be compressed, can be accommodated by the current staging directory size. Therefore, the largest file that FRS can replicate is 2 TB, assuming that the staging directory size is set to the maximum on upstream and downstream partners.
The ratio of staging area size to data set size depends upon a range of factors. For additional guidelines, see article 329491, "Configuring Correct Staging Area Space for Replica Sets" at http://support.microsoft.com/?id=329491.
The largest file that FRS can replicate is determined by the staging directory size on both the upstream and downstream computers. Therefore, the largest possible file that FRS can replicate is 2 TB, when the staging directory size has been set to this maximum value.
Windows 2000 SP2 and later compresses the data in the staging directory. Some file types (text, some binaries, documents) are more compressible than others (compressed archives, and multimedia files).
If you are using Windows 2000 SP2 or earlier, be aware that FRS stops replicating if the staging directory runs out of free space. This means that if a replica set member goes offline for an extended period of time, it does not block replication on an upstream member because the staging directory is filled. Consequently, you should use a generous estimate for staging directory size.
However, Windows 2000 SP3 and later service packs and Windows Server 2003 have an updated staging file management algorithm. On these servers, when FRS tries to allocate space for a staging file and is not successful (because there is not enough space or because the amount of space in use has reached 90 percent of the staging space limit parameter), FRS starts to delete staging files. Staged files are deleted (in the order of the longest time since the last access) until the amount of space in use has dropped below 60 percent of the staging space limit parameter. Consequently, it is not as critical to use as generous an estimate for staging directory size as it was for pre-Windows 2000 SP3 systems, but it is still advised to do so to prevent disk and CPU performance being consumed by repeatedly staging and deleting files.
FRS replicates whole files that have changed, so the rate of change is the sum of the sizes of files modified, not the sum of the sizes of changes to files. There is also the issue of the multiple changes to the same file. FRS can enter a file into the staging directory multiple times — once for each time it was written and closed (but note that the FRS aging cache prevents more than one change order and staging file being generated within 3 seconds).
The ability of downstream partners to accept files is a key factor in determining staging directory size. Other factors here include:
Use the following procedure to adjust the staging directory size.