Note For more information about FSUtil.exe, see the “FSUtil.exe” section on page 31.
 
On a server cluster, before you run chkdsk /f

Note For more information about FSUtil.exe, see the “FSUtil.exe” section on page 31.
-
On a server cluster, before you run chkdsk /f against a volume, you must take offline all other resources in the group that the disk is in.
The Cluster service also has some enhanced volume-corruption-checking options to give you more control over running Chkdsk.
When you try to bring a Physical Disk resource online in Cluster Administrator, you may see one or more of the following symptoms:
-
The Physical Disk resource may fail, or it may come online.
-
The Physical Disk resource may appear to have stopped responding in an Online Pending state.
-
The chkdsk /f command may run on the drive.
-
The following event may be logged in the System event log:
Event ID 1066
Cluster resource Disk Y:: is corrupt. Running ChkDsk /f to repair problems.
When the Cluster service brings a Physical Disk resource online, it checks the volume to see whether the dirty bit is set on the disk. By default, if the dirty bit is set, chkdsk /f is run on the disk before the Cluster service mounts the volume and makes it available to the system.
As an additional check to detect a potential corruption problem, the Cluster service takes the following steps when it brings a Physical Disk resource online:
-
It creates a temporary file (zClusterOnlineChk.tmp) in the root of the drive.
-
It writes a test pattern and then saves the file.
-
It reopens the file, reads the data, and then verifies the data.
-
It deletes the file.
If any part of this process fails, the Cluster service assumes that the disk is corrupted, and chkdsk /f is run.
If the Cluster service can attach to the physical disk but has problems mounting the volume or file system, the Cluster service then tries to run chkdsk /f on the volume in case the volume is corrupted. This can sometimes be misleading when you are troubleshooting because the problem with the volume may not always be corruption; the problem may be another volume-mounting issue.
The following is an example of a Cluster event log of the online process when Chkdsk is run:
00000584.000005dc::YYYY/MM/DD-HH:MM:SS.SSS Physical Disk : DriveLetterIsAlive called for Online check
00000584.00000430:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk: PnP Event GUID_IO_VOLUME_MOUNT for G (Partition1) received.
000009d4.000009f4:: YYYY/MM/DD-HH:MM:SS.SSS [EVT] s_ApiEvPropEvents: Calling into EvpPropPendingEvents, size=648...
000009d4.000009f4:: YYYY/MM/DD-HH:MM:SS.SSS [EVT] s_ApiEvPropEvents: Called EvpPropPendingEvents...
00000584.000005dc:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk : DisksOpenChkdskLogFile: Chkdsk output is in file: E:\WINNT\CLUSTER\Chkdsk_Disk3_Sig3252EAA8.log
00000584.00000430:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk: PnP Event GUID_IO_VOLUME_LOCK for 587488 received
00000584.00000430:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk: PnP Event GUID_IO_VOLUME_DISMOUNT for 587488 received
00000584.00000430:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk: PnP Event GUID_IO_VOLUME_UNLOCK for 587488 received
00000584.000005dc:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk : FixCorruption: Chkdsk returned status of 2.
00000584.000005dc:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk : DisksMountDrives: letter mask is 00000040.
00000584.00000430:: YYYY/MM/DD-HH:MM:SS.SSS Physical Disk: PnP Event GUID_IO_VOLUME_MOUNT for G (Partition1) received.
|