Barracuda XT, Barracuda, Barracuda Green, DiamondMax and other desktop SATA and IDE drives

[berler]

I've been trying to use 4 of the Barracuda LP 2TB ST32000542AS drives (firmware CC34) in RAID5, and they _continuously_ cause the raid array to become "degraded" and rebuilt (which takes about 7 hours).  Several times the array has been reported as completely failed, but after rebooting the array was able to be rebuilt.  I also experienced the "clicking" of death discussed in another thread about these same drives, although the clicking is at random times and much less frequently (maybe once every few days) than reported in the other thread.

Very frequently the raid array "failing" is accompanied by about 15 seconds where the computer completely freezes while trying to access a file on the array (although sometimes the failure occurs when the drives should be idle).

The raid was configured in BIOS (motherboard is a GIGABYTE GA-EX58-UD4P using its onboard raid controller, which is managed as a software raid using Intel Rapid Storage Technology version 9.6.0.1014).

Here is a sample of the event log for the last few days for the raid (so you can see how frequently the raid fails).  The event log looks pretty much the same since I set up the raid a month ago.

Level	Date and Time	Source	Event ID	Task Category
Error	6/16/2010 2:51:32 AM	IAStorDataMgrSvc	0	None	Disk on port 4: Failed.
Error	6/16/2010 2:51:32 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Failed. 
Information	6/16/2010 2:34:35 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.
Information	6/15/2010 7:22:27 PM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding in progress.
Information	6/15/2010 5:21:16 PM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.
Information	6/15/2010 10:31:38 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding in progress.
Information	6/15/2010 7:02:59 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.
Error	6/14/2010 11:01:29 PM	IAStorDataMgrSvc	0	None	Volume BERAID: Failed. 
Information	6/14/2010 3:19:46 PM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.
Error	6/14/2010 7:49:10 AM	IAStorDataMgrSvc	0	None	Disk on port 3: Failed.
Error	6/14/2010 7:49:10 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Failed. 
Information	6/14/2010 7:15:29 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.
Information	6/14/2010 12:21:08 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding in progress.
Information	6/14/2010 12:00:20 AM	IAStorDataMgrSvc	0	None	Volume BERAID: Rebuilding complete.

 The times that the log says "Error" as the level was when a reboot was required to get the raid to rebuild itself; all the other times did not require a reboot and just rebuilt itself.  The fact that two different drives have been showing up as "failed" (on port 3 and port 4) suggests that at least these two drives are having long periods of time of not responding (and perhaps _all_ of them are having problems; it seems if the drive locks up but responds fast enough it just auto rebuilds rather than "failing" requiring a reboot; unfortunately for those times the log does not say which drive caused the problem).

Unfortunately since the drives are connected using the raid controller it is difficult for me to run hd tools programs (for exmaple, seatools does not even recognize the drives as being seagate drives due to the raid controller, although the Intel raid manager program does report their correct model and everything). Also I really don't want to lose the data I have in the raid (about 4 TB, so I really don't have a reasonable way to back this up if I'm going to try debugging the drives with the raid controller turned off)

Has anyone been able to successfully use these drives in RAID5? and if so what do I need to do?  Is it possible to enable ERC so that the raid controller is happy?  or do I just need to buy better (different) drives in order to use RAID?

[Cantbecanit]

Hi, sorry to hear of this problem, I don't use raid myself so I can't be too indepth about it.

The simple things I would check though are these

PSU, looking at your board you will need at least a 600w unit, and always avoid generic ones.

Sata cables, make sure they have no bends or kinks in them, and are good quality ones.

Use the Gigabyte sata/raid driver update found on the MB makers site.

Make sure you have all the bios settings correct, I'm a Gigabyte boy myself, and they can be a bit of a pain to set up, the handbook isn't precise enough imo, although the boards are imo excellent, if your board features the Jmicron and Intel sata ports, i.e some purple and the others orange, some swapping about might help, try running all on the orange slots, or C: on purple and the storage drives on orange.

hth.

[mcsystems]

Dear Sir,

I am a reseller from computer systems and have build for professional reason over the last 3 months 6 systems with a gigabyte GA-P55 USB3 board. All systems are having the OS in RAID 1 (which is WIN7 for 4 systems and XP-pro for 2 others) and I am facing exact the same problem as you described. The raid is degraded without any reason. Even if the system is doing actually nothing. The result is a very slow system and the rebuild of the system takes aprox between 10 till 13 hours ) As I set 3 of 6 systems having this problem continuously ( all 6 systems are having the OS in RAID1 ). I used Samsung disks with one system, Seagate disks with 2 other systems an 3 systems have WD disks. I can assure you that the only overlapping issue here is the main board ( P55 ) chipset. I asked for support of gigabyte and they say that the problem is unknown to them. They asked me to upgrade the Bios to the latest version which I did last week but the customer where I did the first upgrade ( bios version F6 ) called me one day later that the problem was back. I am desperately looking for a solution but do not believe that the HD's are the cause or  the OS ( Win7 and XP used ). It has something to do with the chipset or the software raid driver. All systems have an i5 or i7 core , 4GB ram , 1,5TB HD ( in raid1 and a PSU of 850Watt ( enermax )  which is one of the top PSU builders  .

What you describe as bad SATA cables could be a possible cause but I used the shielded cables which are delivered with the main board. So why do 3 of 6 having this problem .

This is what the system log shows ( it is in Flemish but it says that the IAStorDataMgrSvc service discovered a possible problem on port 4 ( disk on port 4 at risk ????????). There is no reason for

Can anyone help me with this problem

Regards Marc

System log book

_____________

Logboeknaam:   Application

Bron:          IAStorDataMgrSvc

Datum:         16/06/2010 9:44:03

Gebeurtenis-id:0

Taakcategorie: Geen

Niveau:        Waarschuwing

Trefwoorden:   Klassiek

Gebruiker:     n.v.t.

Computer:      SV01

Beschrijving:

Schijf op poort 4: risico.

Disk on port 4: At risk.

Gebeurtenis-XML:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

  <System>

    <Provider />

    <EventID Qualifiers="0">0</EventID>

    <Level>3</Level>

    <Task>0</Task>

    <Keywords>0x80000000000000</Keywords>

    <TimeCreated SystemTime="2010-06-16T07:44:03.000000000Z" />

    <EventRecordID>3461</EventRecordID>

    <Channel>Application</Channel>

    <Computer>SV01</Computer>

    <Security />

  </System>

  <EventData>

    <Data>Schijf op poort 4: risico.

Disk on port 4: At risk.</Data>

  </EventData>

</Event>

[kirkholz]

I am having this problem with a Gigabyte board and the ST32000542AS drives in RAID5 or RAID1. Has anyone found a solution to this problem?

K Holz

[samsonite801]

I had 6 Seagate 500GB drives, 1/2 were NS series (Enterprise) while the other 1/2 were AS series (Desktop) SATA drives, all assembled in a RAID 5 array, using a 3ware 9690 hardware RAID card, and I kept having issues with drive 3 dropping out, and then after reboot and rebuild it would be fine again. I finally discovered that just that drive was set to automatic (1.5 - 3 GB/sec) mode with no jumper while the other 5 drives all had jumpers, so I put in a jumper (which locks it to 1.5 GB/sec SATA) and that fixed the problem. I never had another droppout after that. For whatever reason it just got unstable when set on 3 GB/sec. I never tried switching them all to 3 GB/sec, since 1.5 GB/sec is PLEEENTY fast for me on a RAID 5 array, but I just thought I'd kick in my experience is all. If it has no jumper, then it is set to Auto 1.5 - 3 GB/sec, and if it has a jumper it is set to lock it to only 1.5 GB/sec.