My Intel RST RAID array is "rebuilding", do I have a failed disk?

[tinkeng]

I've tried googling this but haven't found a straightforward answer, or maybe I don't understand the straightforward answer.

I have a Samsung 830 SSD as my OS disk and two 2TB Samsung F4 5400 RPM in RAID 1 (Intel RST RAID and ASUS P8P67 mobo) for storage. Two days ago when I booted I got a bluescreen, the computer rebooted all by itself and the array showed status "Rebuild" after post. Once in Windows I open up the RST software and the status for the array simply says "Volume0: Rebuilding 44% complete". Whatever this means it seems to take a very long time, it's still rebuilding, now at 89%.

So I have a few questions about this:

1. What happened? Has one of my disks failed?

2. If so, how do I check this?

3. What does "rebuilding" mean? Once the array is done rebuilding, will that mean that the array is working again and that I'm protected?

Thanks in advance for an answer.


PS. Sorry for the misspelled title! Title Fixed -B27

 

[ericloewe]

1. Yeah, in some way
2. Open the RST control panel, select the RAID volume and check both drives. One of them will probably say something like "failed"
3. Rebuilding should only happen after you replace the bad drive - basically (for RAID 1), the good drive's contents are copied over to the new drive, restoring the array to its "working" status

As for the failure... Since it's supposedly rebuilding it could just be that the cable got loose, which made the drive unusable. Since you probably used the array when it wasn't complete, the second drive wasn't synced to the first anymore, which required a rebuild.

 

[Ferzerp]

Lots of consumer drives have power saving features that will cause them to temporarily drop out of an array. Look at your specific model, and see if there is a way to disable it (even if it's a disable on every reboot, you can automate it).

 

[ericloewe]

Lots of consumer drives have power saving features that will cause them to temporarily drop out of an array. Look at your specific model, and see if there is a way to disable it (even if it's a disable on every reboot, you can automate it).

Good point, though I haven't seen it happening with consumer RAID. Enterprise solutions are probably more aggressive, though.

 

[alzan]

I've tried googling this but haven't found a straightforward answer, or maybe I don't understand the straightforward answer.

I have a Samsung 830 SSD as my OS disk and two 2TB Samsung F4 5400 RPM in RAID 1 (Intel RST RAID and ASUS P8P67 mobo) for storage. Two days ago when I booted I got a bluescreen, the computer rebooted all by itself and the array showed status "Rebuild" after post. Once in Windows I open up the RST software and the status for the array simply says "Volume0: Rebuilding 44% complete". Whatever this means it seems to take a very long time, it's still rebuilding, now at 89%.

So I have a few questions about this:

1. What happened? Has one of my disks failed?

2. If so, how do I check this?

3. What does "rebuilding" mean? Once the array is done rebuilding, will that mean that the array is working again and that I'm protected?

Thanks in advance for an answer.


PS. Sorry for the misspelled title! Title Fixed -B27

1) Possibly
2) There should be a way within the Windows client to tell if there were bad sectors on one or both of the drives. Alternately you could look at your System Event Log for errors of Types; ntfs, disk, vdisk.
3) Rebuilding on a RAID 1 array equals resynching. Different vendors refer to it as either re-synch or rebuild. All RAID 1 arrays are mirror RAIDs, the contents of the Primary drive are copied to the Secondary and kept in synch.
It is somewhat inaccurate to call it a rebuild on a RAID 1 array but that's another topic.

Hopefully your array has finished the resynch. As a somewhat apples to apples comparison
I've worked with 750GB arrays that took seven hours to complete the resynch and that was within a DOS-like environment, no Windows drivers or other apps. running. Within Windows and with other apps., etc. running on a 2TB drive, I could see it taking 2 days.

But it's also likely that one or both of your drives has enough bad sectors that it's causing the resynch to take this long.

 

[tfgrtr]

There is a quirk in the Intel RST where it will often flag the array to be rebuilt on a warm boot/reset; it seems to be some kind of timing issue with startup of the drives. If you feel confident that you don't have a drive problem you can just cancel the rebuild, but if you don't know the root reason of the problem then you might want to let it finish. I know that with my system with a RAID 1 array if I hit the reset button to reboot it will definitely flag an unnecessary rebuild.

If you open the the RST control panel you can manage all that, and it will report how many media errors that it had to fix.

 

[Ferzerp]

If you feel confident that you don't have a drive problem you can just cancel the rebuild

Any time a drive drops out of an array and even a single write occurs, you *must* rebuild. It's not a matter of "cancel[ing] the rebuild". That will leave you with a degraded array with absolutely no level or protection (unless it's RAID 6). You can't cancel a rebuild and have it pretend nothing happened. It just doesn't work that way. In the case of mirrored drives, that means a complete copy from the drive that didn't drop out to the drive that did. There is no way around it.

 

[tfgrtr]

The first few times this happened to me it rebuilt with zero errors so I just would just cancel it and the volume would continue to function normally.

Other people on the intel and asus forums were having the exact same problem which is a startup timing issue. The drives and the volume are fine, it is a rst/bios bug.

Now, if you want aggravating have a RAID 1 array where the primary drive goes marginal and RST just waits for each sector to time out and reads from the secondary. It doesn't mark the volume or drive as degraded but it runs slow as heck. Of course, doing a rebuild fixes a bunch of errors but it doesn't tell you which drive had the errors, and SMART utilities can't read drive info on the drives because of the array.


Now that I think about it, the status might have been verifying instead of rebuild, though that takes just as long.