FRS Asserts on Primary Member That Contains Large Number of Files or Directories (291165)

IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry

SYMPTOMS

The File Replication service (FRS) is a multi-threaded, multi-master replication engine that replaces the LMREPL service in Microsoft Windows NT 3.x and 4.0. Windows 2000 domain controllers and servers use FRS to replicate system policy and login scripts for Windows 2000 and down-level clients that reside in the system volume.

FRS can also replicate content between Windows 2000 servers that are hosting the samefault-tolerant DFS roots or child-node replicas.

This article describes an error where the Windows 2000 member computers or domains controllers that are marked in the registry or Distributed File System (Dfsgui.msc) snap-in as "primary" for an FRS replica set that contains hundreds of thousands of files:

Fails to inventory all files in the replica tree.
Encounters a journal_wrap error that is typically seen when the FRS service has been turned off for an extended period of time.

The following events are logged in the FRS debug log:

<DbsInitOneReplicaSet:          1428: 11268: S1: 15:45:38> ++ WStatus: 
26-??? -- CMD_JOURNAL_INIT_ONE_RS failed
<JrnlSetReplicaState:           1428:  5787: S4: 15:45:38> :S: Replica (0)
REPLICATEST state change from INITIALIZING to ERROR

CAUSE

When an FRS replica set is created or reinitialized, the "Set Master" command in the DFS Administration tool (or its registry equivalent) is used to define the computer whose files and directory structure will initially be used to populate an FRS replica set.

Prior to replication, the primary FRS member inventories all files in its replicated directories (replica tree) in an effort to populate the IDTABLE (a listing of all files and directories in a replica tree). This "IDTABLE scan" must complete before the the primary member can send change orders or build staging files to downstream partners as a part of the replication process.

The USN journal is a log of fixed size that records all changes that take place on NTFS 5.0 formatted partitions. NTFRS monitors the NTFS USN journal file for closed files in FRS replicated directories as long as FRS is running.

Journal wrap errors occur if a sufficient number of changes take place while the FRS service performs its IDTABLE scan such that the last USN change FRS recorded in the FRS database no longer exists in the USN journal. Because FRS can no longer rely on the USN journal as a source for possible changes in its replica tree, FRS asserts into a journal wrap state. To do otherwise may result in data inconsistency.

MORE INFORMATION

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

Increasing the USN journal size (and accordingly the number of changes it can hold before the journal "wraps"), reduces the chances that the USN journal will wrap. The USN journal size can be changed by setting the amount of megabytes (MB) in the following registry key:

HKLM\System\CCS\Services\NTFRS\Parameters\NTFS journal size in MB (REG_DWORD)

Valid settings range from 8 to 128 MB with a default of 32 MB. This setting applies to all volumes that host an FRS replica tree. Increases to the USN journal size occur after you stop and then restart the NTFRS service. Decreases to the USN journal size can only be made by reformatting all volumes that contain FRS-replicated content.

The number of changes that a given USN journal file can hold can be estimated with the following formula:

<journal size>/((60 bytes + (length of file name)) * 2)

The "2" in the preceding formula stems from 2 journal entries for each file change: 1 for open and 1 for close. Divide the journal size by the size of each change to determine the approximate number of changes that can occur before the journal wrap error occurs. Assuming 8.3 filenames, this maps to approximately 200,000 files or directories for a 32 MB journal file. The number of changes would be less if long file names are used.