Hopefully this is the right thread to ask this....I have a hardware Raid 5 array made up of four 1TB Seagate drives. total available space is about 2.7TB.The operating system is Windows Server 2008 Standard edition and the boot disk is on another drive. The Raid5 drive is just data.Recently something happened and upon a reboot of the server the system wanted to run chkdsk against the Raid5 volume andit was allowed to continue with the chkdsk. it quickly to got to Stage 2 of 3 andit output two lines of text as follows:Correcting error in index $I30 for file 286076.Correcting error in index $I30 for file 286076.and there it stayed. the machine was allowed to stay in this state for 3 days. Finally out of desperation it was hard reset.The server booted and it asked to chkdsk again but it was not allowed. when the OS booted the Raid5 array was checked for consistency. This took about 4 days to complete. quite a long time for a server that was not doing anything at all other than checking the Raid5 volume.all the data is accessible. at least as best as can be determined without attempting to copy the files off the Raid5 volume.ChkDsk was ran from the properties of the volume once the Raid5 consistency check had finished. the system scheduled the chkdsk to run the next time the system booted.the short and long of it is that chkdsk never finishes in a reasonable amount of time. reasonable meaning days, not hours. granted the volume is large, but is there any possibility that chkdsk hangs?to eliminate any hardware issues, the array was moved to another set of hardware with the same OS and same underlining driver architecture. The Raid 5 volume was recognized without a problem. upon reboot, the system wanted to run chkdsk on the volume. it was allowed and it has been in this state now for about 2.5 days. is there a reasonable amount of time that chkdsk should finish in? what are the chances that there is index corruption that chkdsk can't handle and it hangs?these systems are running on Intel E8400 Dual Core processor at 3GHz with 8GB of DRAM.The Raid5 volume is mostly full with about 175GB remaining free.any guidance on this would be greatly appreciated.thanks in advance.Ted S. Antonakis

Hello, Based on your description that, after booting into the system, the RAID 5 volume was checked for consistency; and according to the "Correcting error in index $130 for file xxxx", this seems related to Master File Table corruption. I would firstly double check if you can make sure that all the 'physical disks' in the RAID are working properly, by the hardware RAID specific tools. Then, would you please try booting into Windows Recovery Environment and run CHKDSK there to see how it goes? You can boot from the Setup media and click "Repair your computer" on the Install now page, then click "Command Prompt" on the System Recovery Options page. Besides, this "CHKDSK runs every time you reboot the system" problem may occur if you don't have enough free space on your volume for Windows to allocate space for its internal data structures. The volume will be then marked dirty each time your restart the system. Try the following command to see if any volume is marked dirty: Fsutil dirty query e: (assuming that you are checking the E: drive and, if it is the C: drive, you should move the virtual memory to another drive) If any volume is dirty, also try command "chkdsk e: /f /x". Additionally, I am sorry to say that there is not any reasonable amount of time that chkdsk should finish in. We have even seen that it took more than one week to finish. However, I would like to share some general information on why the stage 2 may take so long time to finish: Phase 2: Checking indexes ================ During its second pass, CHKDSK displays a message that tells you that CHKDSK is verifying indexes and again displays the percent completed, counting from 0 to 100 percent. During this phase, CHKDSK examines each of the indexes on the volume. Indexes are essentially NTFS directories. The "percent completed" that CHKDSK displays during this phase is the percentage of the total number of the volume's directories that have been checked. During this pass, CHKDSK examines each directory that is on the volume, checking for internal consistency and verifying that every file and directory that is represented by a file record segment in the MFT is referenced by at least one directory. CHKDSK confirms that every file or subdirectory that is referenced in a directory actually exists as a valid file record segment in the MFT and also checks for circular directory references. Finally, CHKDSK confirms that the time stamps and file size information for the files are up-to-date in the directory listings for those files. At the end of this phase, CHKDSK has made sure that there are no "orphaned" files and that all directory listings are for legitimate files. An orphaned file is a file for which there is a legitimate file record segment but for which there is no listing in any directory. An orphaned file often can be restored to its proper directory if that directory still exists. If the proper directory no longer exists, CHKDSK creates a directory in the root directory and places the file there. If CHKDSK finds directory listings for file record segments that are no longer in use, or for file record segments that are in use but that do not correspond to the file that is listed in the directory, CHKDSK simply removes the directory entry for the file record segment. The duration of stage 2 varies because the amount of time required to process a directory is closely tied to the number of files or subdirectories listed in that directory. Because of this dependency, the percent complete indicator might not advance smoothly during stage 2, though the indicator continues to advance even for large directories. Best regards,Chang Yin