This is a drive that's been giving me fits.  In my older server, it redballed every couple weeks from what I thought was a bad splitter.  Then I moved it over to my new Norco 4224.  Parity build would complete, but it would redball on parity checks without fail. 

 

This happened with on-board SATA ports, on Sil3132 card, and on AOCSASLPMV8, and on any backplane.  Passed multiple long SMART tests with no pending sectors.  Found out that the file system was bad, ran reiserfsck and fixed.  ... Redballs went away completely.  Four or five random parity checks no problem for over a week.

 

I didn't trust this drive at all, so I transferred all the data off to a reliable drive; precleared it x2 and I relegated it to warm spare duty and literally put a share "Junk" on it just to give it a little payload.  Out of the corner of my eye, like a hawk I have been watching the syslog.  No rpoblems for the last two weeks.

 

Last night, I ran a parity check overnight into the morning.  60% through, my daughter plays a cartoon at about 7am (from a separate totally non-associated share/drive)... and out of nowhere I get a hiccup:

 

 

 

Mar  5 06:56:13 Tower kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x80000 action 0xe frozen (Errors)

Mar  5 06:56:13 Tower kernel: ata2.00: irq_stat 0x00100010, PHY RDY changed (Drive related)

Mar  5 06:56:13 Tower kernel: ata2: SError: { 10B8B } (Errors)

Mar  5 06:56:13 Tower kernel: ata2.00: failed command: READ DMA EXT (Minor Issues)

Mar  5 06:56:13 Tower kernel: ata2.00: cmd 25/00:08:a8:c2:03/00:00:81:00:00/e0 tag 0 dma 4096 in (Drive related)

Mar  5 06:56:13 Tower kernel:          res 5a/37:00:00:00:00/00:00:00:00:5a/00 Emask 0x12 (ATA bus error) (Errors)

Mar  5 06:56:13 Tower kernel: ata2.00: status: { DRDY DRQ } (Drive related)

Mar  5 06:56:13 Tower kernel: ata2.00: error: { IDNF ABRT } (Errors)Mar  5 06:56:13 Tower kernel: ata2: hard resetting link (Minor Issues)

Mar  5 06:56:21 Tower kernel: ata2: softreset failed (SRST command error) (Errors)

Mar  5 06:56:21 Tower kernel: ata2: reset failed (errno=-5), retrying in 3 secs (Minor Issues)

Mar  5 06:56:23 Tower kernel: ata2: hard resetting link (Minor Issues)

Mar  5 06:56:25 Tower kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) (Drive related)

Mar  5 06:56:26 Tower kernel: ata2.00: configured for UDMA/100 (Drive related)

Mar  5 06:56:26 Tower kernel: ata2: EH complete (Drive related)

 

We've all seen these before. 

 

Is it possible that the electronics on the drive are bad?  I've troubleshot this drive to death.  Any port where it's seemingly had trouble, another drive runs without a hitch.  I'm thinking about RMA'ing this drive.  Any advice/input?

 

Thanks!

If it is still in warranty I would RMA, an unstable drive is even worse than pending or other sectors. It can breakdown any moment Can be a hardware defect.

 

Did you try other cables?

Yeah I've tried other cables.  It's been on every controller/port/backplane/slot on my Norco 4224.  Mobo SATA ports, Sil3132, SASLPMV8 tried them all.  The Norco makes it relatively easy to do the trouble shooting.  Just have to power down, move the drive to another bay, restart.  It's just then we get to suffer the indignity of a day long (~10 hours) stress test that is the parity check. 

 

Sooner or later, it's thrown an error.  This little hiccup recently (the first in 2 weeks) was the least of it.  Those redballs during earlier parity checks made my sphincter tighten.  Remember this is a drive that redballed a few times on an entirely different rig before I ported it over to the Norco.  I worry I have been lulled into a false sense of security ever since re-preclearing the drive and the passed SMART's. 

 

Like I was saying, anywhere it's failed, any other drive has done fine.  Like if I move a known stable drive to the port that was previously occupied by this suspect drive: I have not yet seen an error arise from a good drive from that vacated port.

 

We've all blamed bad cables traditionally.  But it seems I think that I've eliminated cables/controllers from the equation.  I just wanted to see if the opinion was out there that glitchy electronics (passed pre-clear x 2 ; passed SMARTs) can throw the aforementioned type of error.  Tell me that there is no way this error comes from anything other than bad cabling/controller then I'm going to really have to scratch a temple.

 

 

Welp.  This one came to a quick resolution.  It was a bad drive after all.  About two days after I posted those errors, I ran a parity check and the drive redballed.  Now it's completely dead.  It takes juice, but is no longer recognizable.  In previous redballs, a reset would allow it to come back online and I could re-"trust" the drive.

 

Sending this one in for RMA.  I think that IDNF error was a dead giveaway.  Supposedly that's a serious drive error, and I wasn't supposed to trust that drive. 

 

I just wanted to see if anyone else had a similar experience where a drive failed without any pre-existing/known SMART issues.  I'm not versed in the workings of an HDD, but I'm curious what type of failure would allow for this slow death.