And if chkdsk is not recommended for this task fixing minor inconsistencies in the file system , what is the alternative? There are circumstances where the logical contruct similarly appears to have errors. When CHKDSK inspects the logical structure it may force the controller to detect a physical error, causing the cotroller to attempt recovery at the physical layer. I think that's the thing. But, then again, why bother with the RAID utility?
Consistency Check is a background operation that verifies and corrects the mirror or parity data for fault tolerant virtual disks. It is recommended that you periodically run a consistency check on virtual disks. If performed from the firmware you may get a choice as to online or offline, though for 'verify' this is a rarer choice than during 'build'.
If I had problems with the array I may just prefer to verify while offline. If I was only doing it as part of regular maintenance I would verify while online. I just hope it offers me a 'non-destructive' verify, i. During a verify the controller asks the drive to read each sector on disk. If all is good, we have nothing to worry about. Also, the drive itself also has error handling routines. A read from the platter may have errors that the drive itself will attempt to fix.
Again, no error, no problem. But what happens if there is an error on the magnetic platter itself? Single bit errors, even multi-bit errors, are handled by the drive and things like 'CRC error detection', 'parity bits' and 'checksum', but there is the possibility that there are more errors than the drive logic can handle.
This is no different than a single drive alone. Next step up is the raid array itself. Despite all the previous error detection and correction the array may still contain errors. But it still may be outside the capabilities of the system to correct such. RAID makes a best effort, as does the drive itself, and later on in the process so does your file system, but no matter how many checks and balances you have in place, sometimes it goes wrong.
Hi SG, thanks for your detailed reply. It sort of spelled out what I believed to be the case. All the more reason that I am surprised that I am having to do this at all. It's not unknown for RAID5 to get into a 'torn' state where the array needs to be fully re-initialised. My appologies as my alerts were not configured properly on this forum, therefor I did not see your reply question until just now.
There are some steps you might try, from Array manager, drill down to the individual disks and view the properties. This should show any errors on the physical disks. It would give you a starting point in your investigations. Make sure the array is at the latest firmware E Raid contoller firmware and drivers is always a good bet as well.
I would invest in enterprise level disk tools, like diskeeper. Probably more efficient than the built in version, plus you can schedule defrags. The first time you run defrag, it will take a long time. After that scheduled defrags will be quicker. If you using the newest version 5. You can manually run a consistency check in Storage Management using these instructions.
Go to a command line and run the following command to display the virtual disks and controllers. You do this because in the batch file you will have to specify the controller and virtual disk you would like to scan. You will need to create one for each virtual disk you would like to check. Inside the file you will add the necessary commands to check the consistency on the selected virtual disk and controller.
Once that is complete you will use the Windows Task Scheduler Wizard to run the batch file during off peak hours. Click next and follow the onscreen directions. Click Browse and locate the batch file you created above. Chkdsk being run on one of the disks. RAID 5 initialization being performed. A RAID 5 continues to function in degraded mode after one disk fails. The user is supposed to replace the bad disk with a new disk and perform a rebuild to regenerate the lost data using parity data on the remaining disks.
When the rebuild is complete, the RAID will be restored to its normal state. Things that can go wrong include: Instead of the bad disk, a good disk is inadvertently replaced. When the good disk is disabled to prepare for replacement, the RAID immediately fails because it cannot operate with two disks offline. However, more mistakes may lead to permanent data loss. The number of disks is incorrectly specified during the rebuild.
For example, a six-disk configuration with a hot spare disk is actually a 5-disk RAID.
0コメント