The consistency check that Todd mentions is for verifying the raid (parity) and is definitely a good thing to do.
However, things like poweroutages or unexpected/forced shutdowns (e.g. BSOD) could force a chkdsk of the filesystem (which the raid controller cannot do anything for).
What you're running into is the downside to having huge disks; when a chkdsk is needed/forced you incurr a lot of downtime. You could check out this article and enable journaling on the disk(s). It could reduce the chance of getting a forced chkdsk, but as the article states, you'll still want to run a chkdisk from time to time.
Thanks again, both of you. My newly created array is actually running a consisency check right now, so when that finishes, I'll start a consistency check on the other drives (one at a time).
A Consistency Check will only take the place of a CHKDSK if the Windows file system corruption is caused by inconsistencies in the RAID array. There is still a chance that you will need to run a CHKDSK, but if you have not been running regular Consistency Checks, then there is a good chance that is your cause.
Well, we did just have some issues with the other storage modules while hooking up the new one. Drives seemed to go off line and then back on line. It was weird to say the least. So, I may not get out of the woods with a consistency check. If I have to let the CHKDSK run, I guess I will fire it up late afternoon and let it run overnight.
"Drives seemed to go off line and then back on line"
The drives are not going offline , then recovering , this is not a function of the raid adapter; under certain circumstance arrays can appear unresponsive, most of the time it due to the OS or network issues, though firmware on the drives/raid adapter or a failing electronic component failure could cause odd behavior (very rare).
Aside from the consistency check, also look at the Storage Manager events for any errors found during Patrol Reads, which checks every sector on the array disk, not just the data area. This runs in the background as a default. If after the CC and checking the log for PR; with no errors found , the array subsystem as to the array format and physical disk errors can be basically ruled out. Bugs in the firmwares still could be a possibility but rare. Shame chkdsk is so time consuming once you need to run it with the /F switch, hope it unneeded. How did the chkdsk fair?
Haven't run the CHKDSK yet. Had to let a initialization run on a newly created array.
This morning I started a consistency check on one of the suspect arrays, and it's only half way finished right now. When that finishes I will do the consistency check on the other suspect array.
If the consistency checks don't arrest the problem, I will schedule a CHKDSK.
I'll post my results as to what worked, what didn't.
Dev Mgr
4 Operator
•
9.3K Posts
0
June 29th, 2011 08:00
The consistency check that Todd mentions is for verifying the raid (parity) and is definitely a good thing to do.
However, things like poweroutages or unexpected/forced shutdowns (e.g. BSOD) could force a chkdsk of the filesystem (which the raid controller cannot do anything for).
What you're running into is the downside to having huge disks; when a chkdsk is needed/forced you incurr a lot of downtime. You could check out this article and enable journaling on the disk(s). It could reduce the chance of getting a forced chkdsk, but as the article states, you'll still want to run a chkdisk from time to time.
KBeau
2 Intern
•
387 Posts
0
June 29th, 2011 08:00
Thanks again, both of you. My newly created array is actually running a consisency check right now, so when that finishes, I'll start a consistency check on the other drives (one at a time).
theflash1932
9 Legend
•
16.3K Posts
0
June 29th, 2011 08:00
A Consistency Check will only take the place of a CHKDSK if the Windows file system corruption is caused by inconsistencies in the RAID array. There is still a chance that you will need to run a CHKDSK, but if you have not been running regular Consistency Checks, then there is a good chance that is your cause.
KBeau
2 Intern
•
387 Posts
0
June 29th, 2011 08:00
Well, we did just have some issues with the other storage modules while hooking up the new one. Drives seemed to go off line and then back on line. It was weird to say the least. So, I may not get out of the woods with a consistency check. If I have to let the CHKDSK run, I guess I will fire it up late afternoon and let it run overnight.
My fingers are crossed!
KBeau
2 Intern
•
387 Posts
0
June 29th, 2011 08:00
Thanks Todd!
Now, will the consistency check stop Windows from wanting to run a chkdsk at start up?
And, while the consistency check is running, is the array still accessible?
Lastly, about how long do you think it will take, per array?
KBeau
pcmeiners
4 Operator
•
1.8K Posts
0
June 30th, 2011 13:00
"Drives seemed to go off line and then back on line"
The drives are not going offline , then recovering , this is not a function of the raid adapter; under certain circumstance arrays can appear unresponsive, most of the time it due to the OS or network issues, though firmware on the drives/raid adapter or a failing electronic component failure could cause odd behavior (very rare).
Aside from the consistency check, also look at the Storage Manager events for any errors found during Patrol Reads, which checks every sector on the array disk, not just the data area. This runs in the background as a default. If after the CC and checking the log for PR; with no errors found , the array subsystem as to the array format and physical disk errors can be basically ruled out. Bugs in the firmwares still could be a possibility but rare. Shame chkdsk is so time consuming once you need to run it with the /F switch, hope it unneeded. How did the chkdsk fair?
KBeau
2 Intern
•
387 Posts
0
June 30th, 2011 16:00
Haven't run the CHKDSK yet. Had to let a initialization run on a newly created array.
This morning I started a consistency check on one of the suspect arrays, and it's only half way finished right now. When that finishes I will do the consistency check on the other suspect array.
If the consistency checks don't arrest the problem, I will schedule a CHKDSK.
I'll post my results as to what worked, what didn't.
Finger crossed I don't need to do a CHKDSK!
KBeau