The following summary describes specific improvements that were made to the Windows 2000 Chkdsk utility:
File verification (stage 1) and security verification (stage 3) are each as much as three times faster than in Windows NT. Additionally, both stage 1 and 3 are now dual-threaded to maximize throughput.
Index verification (stage 2) was the most time-consuming and complex stage in earlier versions of Windows NT. This has been improved in Windows 2000 from no change (in special cases) to at least nine times faster. The volumes that take the longest time in Windows NT 4.0 Chkdsk will most likely hit the high end of the improvement.
The progress indicator for the index verification stage has been improved so that it is now more closely proportional to the number of index entries that are checked. It will not be as likely to give the user the impression that Chkdsk is “hung” (has stopped responding) when the progress indicator remains at a certain percent for a long time when Chkdsk checks a folder that contains the majority of the files in the volume.
Improvements have also been made in processing fragmented or compressed files. In testing, Chkdsk was run on a single 0.5 gigabyte (GB) fragmented file, and it finished running in 30 seconds (as compared to 450 seconds on Windows NT). Note that this is a 15-fold increase in speed.
Microsoft added two command-line switches (the /i option and the /c option) to Chkdsk to allow for brief index verification and to skip cycle checking. When used together on a huge volume, you can save a lot of time. This is particularly useful if you do not care about the complete correction of directories.
Improvements have also been made in processing files with huge amounts of data streams or huge attribute lists (which typically results because of huge file size or fragmented or compressed files). In testing, Chkdsk was run on a single file with 5600 data streams, and it took 208 seconds (as compared to 14,164 seconds on Windows NT). This is a 68-fold increase in speed.
Note For more information, see the following Microsoft Knowledge Base articles:
187941 “An Explanation of Chkdsk and the New /c and /i Parameters”
Microsoft has a dedicated team that looks at all aspects of Windows 2000 performance. The team tested Chkdsk on a 45-GB volume (95 percent in use) that contained almost 2 million files and 236,500 indexes. Under Windows NT 4.0 Service Pack 3 (SP3), Chkdsk took 33 hours to run. Under Windows 2000, Chkdsk took 100 minutes — a 20-fold time reduction.
Caveat All figures were calculated from tests that were run on fabricated test environments. While every effort was made to replicate real world scenarios, the team could not test every variety of hardware our customers have deployed or the many combinations of disk and file configurations that exist. Therefore, use the results as a guide only. It is the responsibility of our customers to apply best practice principles and evaluate the impact of the improvements in their specific environments.
Larger amounts of RAM will increase Chkdsk performance in Windows 2000 and beyond.
Table 9: Chkdsk Performance Results
2 Million Files
3 Million Files
Windows NT 4.0 SP6
and Windows .NET Server 2003
Important To obtain the best Chkdsk performance, apply the most recent service pack for your operating system.
How Long Will Chkdsk Take to Run?
The number one question Microsoft Product Support Services is asked is: “Exactly how long is Chkdsk going to take?” And the answer is: We don’t know. There is no magic formula that can tell you how long Chkdsk will take to run. Running Chkdsk can take anywhere from a few seconds to several days, depending on your specific situation.
The “Chkdsk Phases” section earlier in this document gives you only a broad outline of the most important tasks that Chkdsk performs to verify the integrity of an NTFS volume. Chkdsk also makes many additional specific checks during each pass and several quick checks between passes. The following list describes the variables that also affect the length of time that Chkdsk takes to run.
Variable 1: The “Indexes” Phase
During the first phase (checking files) and the third phase (checking security descriptors), the progress of the “percent completed” indicator is relatively smooth. Unused file record segments do require less time to process, and large security descriptors do take more time to process, but overall the “percent completed” is a fairly accurate reflection of the actual time that the phase requires. The second phase (checking indexes) is the one that typically takes the longest to run.
Variable 2: The Condition of the Volume
The condition of a volume plays a role in how long Chkdsk takes to run. If there were a formula for predicting the time that it takes to run Chkdsk on a particular volume, it would include such variables as the number of files and folders, the degree of fragmentation of the volume and of the MFT in particular, the format of file names (long names, 8.3-formatted names, or a mixture), the number of bad sectors on the disk, and the amount of actual corruption that Chkdsk must repair. All else being equal, Chkdsk times typically increase linearly with respect to the total number of files and folders on a volume.
Variable 3: Hardware Issues
Hardware issues also affect how long it takes for Chkdsk to run. The variables include the available memory, CPU speed, I/O throughput (fibre channel or Small Computer System Interface [SCSI]), disk RPM speed, and others.
Variable 4: The Chkdsk Settings
If you use the /r command-line switch, Chkdsk has to read and verify every sector on the volume, which adds significantly to the time that it takes for large volumes.
If you do not use the /r option, the biggest time issue on a particular hardware platform is the number of files and folders that are on the volume, instead of the absolute size of the volume. For example, a 50-GB volume that has only one or two large database files might take only seconds for Chkdsk to run. On the other hand, running Chkdsk on even a relatively small volume might require hours if the volume has hundreds of thousands or even millions of small files — regardless of whether you specify the /r option.
About Running Chkdsk in Read-only Mode
The best way to predict how long Chkdsk will take to run on a particular volume is to actually do a trial run in read-only mode during a period of low system usage. However, you must use this technique with great care for the following reasons:
In read-only mode, Chkdsk quits before it completes the first three phases if it finds inconsistencies, and Chkdsk is prone to falsely reporting errors when it runs in read-only mode. For example, Chkdsk may report disk corruption if NTFS happens to modify areas of a disk while Chkdsk is examining the disk. For correct verification, a volume must be static, and the only way to guarantee a static state is to lock the volume. Chkdsk locks the volume only if you specify the /f command-line switch (or the /r option, which implies /f). You may have to run Chkdsk more than one time to get Chkdsk to complete all its passes in read-only mode.
Chkdsk is both CPU intensive and disk intensive. The time that it takes to run Chkdsk is affected by how much load is on the system and whether Chkdsk runs online or during the Windows 2000 startup sequence. Which factor becomes the bottleneck depends on the hardware configuration, but high CPU usage or heavy disk I/O while Chkdsk is running in read-only mode increases the Chkdsk running time. Also, Autochk.exe runs in a different environment from that of Chkdsk.exe. Running Autochk.exe gives Chkdsk exclusive use of CPU and I/O resources, but it also prevents Chkdsk from using virtual memory. Although you might expect Autochk.exe to run faster than Chkdsk.exe, Autochk.exe may actually take longer if the computer has relatively little available RAM.
Fixing corruption adds to the time that it takes. In read-only mode, Chkdsk runs until it is complete only if Chkdsk does not find any significant corruption. If a disk shows only minor corruption, fixing the problems will not add much to the time that it takes just to run Chkdsk. But if Chkdsk finds major damage — for example, from a serious hardware failure — the time will increase in proportion to the number of damaged files that Chkdsk must repair. In extreme cases, this can more than double the time that it takes for Chkdsk to run.
Running Chkdsk and correcting file system corruption after it has occurred is only a reactive measure. To best do this, you must understand what Chkdsk is, what it does, and how you can correct the corruption. However, after you have addressed the corruption, you must take corrective steps to identify the source of the corruption and correct it.
For more information about Chkdsk, see the following book and Microsoft Knowledge Base articles:
Inside Microsoft Windows 2000, Third Edition from Microsoft Press®
187941 “An Explanation of Chkdsk and the New /c and /i Parameters”
191603 “Modifying the Autochk.exe Time-out Value”
160963 “CHKNTFS.EXE: What You Can Use It For”
280353 “How to Change Quorum Disk Designation”
265533 “Explanation of Chkdsk Status Codes in Cluster Log”
272244 “Location of the Chkdsk Results for Windows Clustering Resources”
176970 “How to Run the Chkdsk /f Command on a Shared Cluster Disk”
218461 “Enhanced Chkdsk, Autochk, and Chkntfs Tools in Windows 2000”
How to Automate Chkdsk
If you run Chkdsk with the /f command-line switch to fix corruption, in most cases there will be locked files, and you must restart the computer to have exclusive access to the partition or partitions. Typically, you have to press Y to schedule Chkdsk to run in write-mode on the next restart. However, you can automate this process so that no user intervention is required.
To automate Chkdsk, create the following batch file, and then disseminate it to the preferred system or systems:
echo y|Chkdsk [destination drive:] /f/r
rem sleep 3600
rem c:\utils\shutdown.exe /l /r /y /t:6
The last two lines are optional. Sleep.exe and Shutdown.exe are from the Windows Resource Kit. “Sleep 3600” causes the system to wait for 60 minutes before proceeding to the next line in the batch file. Shutdown.exe is then called to shut down and then restart the target system. If Shutdown.exe is not called, and the drive could not be locked for exclusive use, Chkdsk runs the next time you manually restart the target system.
If you want to schedule Chkdsk, or this batch file, to run on specific days or times, use the Task Scheduler or AT Scheduler (the command-line interface).
Windows XP and Windows .NET Server 2003 include a new command-line utility that is named FSUtil.exe. FSUtil has several uses beyond the scope of this white paper that will not be discussed. To augment your use of Chkdsk and Chkntfs, you can also use FSUtil to modify the dirty bit in the MFT on the physical disk on a Windows 2000–based computer, a Windows XP–based computer, or a Windows .NET server–based computer.
To manage the volume's dirty bit, use the Dirty command. To then change or check the status of the dirty bit, use the Set or Query command. Note that you can also use the Chkntfs command to check whether the dirty bit is set. However, you cannot use Chkntfs to set the dirty bit.
To query the current status of the dirty bit on a volume, use the following command:
fsutil dirty query drive:
To manually set the dirty bit on a volume, use the following command:
fsutil dirty set drive:
For both commands, replace drive with the drive letter of the volume that you want to manage.
For example, to query the dirty bit on drive C, type: