Hi all,

 

i have a unraid 4.51 server running 14 Seagate 1,5TB discs on a Asus P5B-VM DO with a C2D E4500 and 4 GB ram plus two Adaptec 1430SA, working flawless so far.

 

Since i maxed out all SATA connectors i decided to replace the parity disc with a WD EADS 2TB this worked without a hickup, then i needed to replace the first data disc with a new WD 2TB, i did a parity check befor to be safe which ran successfully.

 

But now when i try to rebuild the first data disk onto the new WD drive it's failing, i tried this severall times now ... the first 2 tries stopped after 10 minutes with write errors on the disc. I removed the disc and did a surface check with the WD health tool which came out clean!

 

The 3rd attempt run for about 50% and stopped again ...

 

Can someone have a look at my syslog (http://pastebin.com/pzEDv3P7) and give me some advice? I just suspect the disc to be bad...

 

I'll try to run a long smartcheck now but i allways find me struggelign to interpret the outcome...

 

Thanks in advance.. Mason

 

Hhhhhmmmm.... Seems to be a lot of "kernel: handle_stripe write error:" errors. It could mean that the unRAID OS is detecting the sectors to that part of the drive is bad. It will find the correct data from other parts of the drive by trying to write over the block(s) that failed and then try to read it back from those bad block(s) again.

If either the write or the re-read fails, the md command will treat the error the same way that a write error is treated and will fail the whole hard drive. Do a low-level format on it and try and iron out the drive and then attempt to re-use it. Hope this helps!

thanks for you toughts, im running a long smart test right now and will see what the outcome is here.

Hopefully it shows up with bad blocks, then I'm going to RMA the drive ...

More often than not there symptoms are the result of a bad or lose cable or backplane connection. The way to tell for sure is to look at a smart report from the drive and see if there are reallocated or pending reallocated sectors. If there are more tjan a few, and esp if the number is increasing with usage, the drive needs to be replaced. But if those counts are zero but you see log entries indicating unknown commands and/or invalid disk addressess, it means the signal from computer to drive is getting garbled.

 

BTW a long smart test happens 100% on the drive and does not exercise to I/F to the computer.

More often than not there symptoms are the result of a bad or lose cable or backplane connection. The way to tell for sure is to look at a smart report from the drive and see if there are reallocated or pending reallocated sectors. If there are more tjan a few, and esp if the number is increasing with usage, the drive needs to be replaced. But if those counts are zero but you see log entries indicating unknown commands and/or invalid disk addressess, it means the signal from computer to drive is getting garbled.

 

BTW a long smart test happens 100% on the drive and does not exercise to I/F to the computer.

Another clue you've lost connectivity to the drive is the number of "write" errors..  It just so happens that 288 is the size of the "md" device sync window.  You'll see it in your syslog as:

Feb 28 16:39:02 Tower kernel: mdcmd (4): set md_sync_window 288

 

In other words, look for a loose cable or connection. (On either the power or SATA connection)

 

Basically, the kernel attempted to reset the disk after a timeout error:

Mar  3 02:23:42 SPACEHOG kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar  3 02:23:42 SPACEHOG kernel: ata14.00: cmd 35/00:00:07:50:d4/00:04:8e:00:00/e0 tag 0 dma 54288 out

Mar  3 02:23:42 SPACEHOG kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar  3 02:23:42 SPACEHOG kernel: ata14.00: status: { DRDY }

Mar  3 02:23:42 SPACEHOG kernel: ata14: hard resetting link

Mar  3 02:23:48 SPACEHOG kernel: ata14: link is slow to respond, please be patient (ready=0)

Mar  3 02:23:52 SPACEHOG kernel: ata14: COMRESET failed (errno=-16)

Mar  3 02:23:52 SPACEHOG kernel: ata14: hard resetting link

Mar  3 02:23:58 SPACEHOG kernel: ata14: link is slow to respond, please be patient (ready=0)

Mar  3 02:24:02 SPACEHOG kernel: ata14: COMRESET failed (errno=-16)

Mar  3 02:24:02 SPACEHOG kernel: ata14: hard resetting link

Mar  3 02:24:08 SPACEHOG kernel: ata14: link is slow to respond, please be patient (ready=0)

Mar  3 02:24:38 SPACEHOG kernel: ata14: COMRESET failed (errno=-16)

Mar  3 02:24:38 SPACEHOG kernel: ata14: limiting SATA link speed to 1.5 Gbps

Mar  3 02:24:38 SPACEHOG kernel: ata14: hard resetting link

Mar  3 02:24:43 SPACEHOG kernel: ata14: COMRESET failed (errno=-16)

Mar  3 02:24:43 SPACEHOG kernel: ata14: reset failed, giving up

Mar  3 02:24:43 SPACEHOG kernel: ata14.00: disabled

 

Once the disk was disabled, all the write attempts in the buffer cache failed. (all 288 of them)

 

In order to run a "long" smart test you will need to disable the spin-down timer, since spinning down the disk will terminate any test that is running.

 

Joe L.

Thanks for all the advice guys, i allready disabled spindown for the test and i allready changed the cable after the first failed attempt but the explanation makes sense.

 

I lost track over all the SATA cables i've got, maybe i should dump them all and just buy a batch of new ones. Besides that these SATA cables are nice and small, connectivity with these seems to be 'the horror'.

 

I'll get back with results...

I upgraded to locking cables and have had far fewer problems with cabling ever since.  But some controllers don't have the locking mechanism on the SATA ports.  On these you can sometimes get the locking cable on them (of course they don't lock but are usually very tight) or you have to use a non-locking cable.

Yeah the lock-type SATA cables are way better. Changing over the cabling to test if this is the problem is the quickest troubleshooting technique. It's funny cabling just goes like that, though if you give it too much bending or bend it at a strong angle (especially SATA cabling) you can easily damage the cores of the wiring.

Update:

 

After SMART showed up some unusual high reallocation count and such, i just decided to RMA the drive. Since it was brand new, I got it exchanged pretty fast. Just stuffed it in, rebuilded and after 10 hours everything is back to normal again.

 

Now im struggeling with my confidence in WD after 2 DOA drives, but maybe they just got a bad batch !?

 

Thanks for the aid guys