I have the following setup (this is a test system, with no production data, so data loss is NOT a concern)
Intel DG45ID mainboard,
Intel RS2MB044 RAID controller,
-- 1x OCZ Vertex 2 SSD on a 8087-to-4xSATA cable on the internal port
-- RES2SV240 expander connected by 8088-to-8087 cable to the external port
-- 16x WD Red 30EFRX 3TB drives connected to RES2SV240 by 4x 8087-to-4-SATA cables.
Logically, the system is set up with two identical RAID6s combining 8x WD Red drives per array, plus one RAID0 for SSD, providing readonly CacheCade.
The immediate problem is that the RAID controller starts beeping every reboot, something like one second on then one second off. When the system starts up, and Windows boots, I have to use RAID Web Console 2 to silence the alarm. However, there is no readily identifiable problem with the controller. RAID Web Console 2 lists "Controller condition optimal", "BBU optimal", All drives "Online", and 2x RAID6 arrays "Optimal". Also, no background tasks are running, no rebuild or whatever.
How do I identify what is the problem it beeps about?
Has your system had a drive failure with a hot spare replace scenario?
If so, the firmware recognizes that a hot spare was used to replace a failed drive and that the system is beeping because it expects that the customer will wish to perform a copy back procedure to put the disk/slot order back into the original config. If the customer recreates the hot spare the beeping will cease, and the customer can then choose whether or not to do a copy back.
Copy back works like this:
1. Disk in slot one fails and hot spare drive in slot ten automatically starts to rebuild (this is called "commissioning" the hot spare). Beeping will continue during the rebuild unless silenced because the VD is degraded.
2. Rebuild completes and customer inserts a new drive into slot one. Beeping frequency changes to but continues because a hot spare does not yet exist and the configuration is not degraded, but is still not as original.
3. Customer makes disk in slot one the hot spare, beeping should stop and the customer should be prompted to perform a copy back procedure. In this procedure, the data is copied from the disk in slot ten to the disk in slot one, and the disk in slot ten becomes the hot spare drive; and the configuration is back to the original configuration.
Nope, the system never had a hotspare configured.
Apparently, the problem went away after a manual battery relearn cycle, so it must have been related to BBU. I still find it strange that there was no indication pointing to BBU whatsoever, but it seems solved for now.