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
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.
Two options are available to resolve this problem:
- Increase the size of the NTFRS USN journal on the volume that hosts the FRS-replicated content.
- Reduce the number of files that are located in the replica tree until the initialization phase has completed.
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.
: 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
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.