Unraid Version is 4.6

Syslog is attached.

 

So I bought an EARS drive WDC_WD20EARS-00MVWB0

 

When I jumper 7-8 and put it in the unraid server, and boot, a lot of errors come up from it during the boot process.

In fact it takes it about 4 minutes to move past this one disk:

When I unjumper it, no errors occur.

 

I'm not sure if this is normal with these EARS drives or if it is a sign of a bad disk?

The errors also occur when I try to run a preclear on it.. but it does eventually move on.

 

Is this normal? Or should this be returned?

 

Jan 21 13:56:32 Tower kernel: ata4.00: failed command: READ DMA EXT

Jan 21 13:56:32 Tower kernel: ata4.00: cmd 25/00:08:a8:88:e0/00:00:e8:00:00/e0 tag 0 dma 4096 in

Jan 21 13:56:32 Tower kernel:          res 51/01:00:af:88:e0/d6:00:e8:00:00/e0 Emask 0x1 (device error)

Jan 21 13:56:32 Tower kernel: ata4.00: status: { DRDY ERR }

Jan 21 13:56:32 Tower kernel: ata4.00: configured for UDMA/33

Jan 21 13:56:32 Tower kernel: ata4: EH complete

Jan 21 13:56:35 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Jan 21 13:56:35 Tower kernel: ata4.00: irq_stat 0x40000001

Jan 21 13:56:35 Tower kernel: ata4.00: failed command: READ DMA EXT

Jan 21 13:56:35 Tower kernel: ata4.00: cmd 25/00:08:a8:88:e0/00:00:e8:00:00/e0 tag 0 dma 4096 in

Jan 21 13:56:35 Tower kernel:          res 51/01:00:af:88:e0/d6:00:e8:00:00/e0 Emask 0x1 (device error)

Jan 21 13:56:35 Tower kernel: ata4.00: status: { DRDY ERR }

Jan 21 13:56:35 Tower kernel: ata4.00: configured for UDMA/33

Jan 21 13:56:35 Tower kernel: ata4: EH complete

Jan 21 13:56:38 Tower kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

Jan 21 13:56:38 Tower kernel: ata4.00: irq_stat 0x40000001

Jan 21 13:56:38 Tower kernel: ata4.00: failed command: READ DMA EXT

Jan 21 13:56:38 Tower kernel: ata4.00: cmd 25/00:08:a8:88:e0/00:00:e8:00:00/e0 tag 0 dma 4096 in

Jan 21 13:56:38 Tower kernel:          res 51/01:00:af:88:e0/d6:00:e8:00:00/e0 Emask 0x1 (device error)

Jan 21 13:56:38 Tower kernel: ata4.00: status: { DRDY ERR }

Jan 21 13:56:38 Tower kernel: ata4.00: configured for UDMA/33

Jan 21 13:56:38 Tower kernel: sd 4:0:0:0: [sdd] Unhandled sense code

Jan 21 13:56:38 Tower kernel: sd 4:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08

Jan 21 13:56:38 Tower kernel: sd 4:0:0:0: [sdd] Sense Key : 0x3 [current] [descriptor]

Jan 21 13:56:38 Tower kernel: Descriptor sense data with sense descriptors (in hex):

Jan 21 13:56:38 Tower kernel:         72 03 13 00 00 00 00 0c 00 0a 80 00 00 00 00 00

syslog.txt

Has this drive previously been used in another machine perhaps?

 

If so, then these tend to appear in the syslog.  You should be able to run preclear on the drive anyway, though more of these errors will still appear until preclear is finished.  There is a long thread (probably in the Hard drives forum) related to these drives.

It seems like the drive was used previously without the jumper on it.

 

If I were in your situation, I would use the drive without the jumper with unRAID 4.7 beta 1, the latest version of the preclear_disk script, and opt for the Advanced Format setting(s).

Well it was just bought from the store. In original packaging. And put into the unraid machine. So, I wouldn't think it was previously used.

 

I am currently following the piece of advice here: http://lime-technology.com/forum/index.php?topic=5384.msg84641#msg84641 and doing a low level format on it.

I'll update if that fixes it.

 

 

Yuk, low level formatting tool...

 

There is a command dd in unRAID that can be used to clear the drive.

 

I too would do as BRiT suggests. Just forget about the jumper and format it with a sector 64 partition using unRAID 4.7b1.

 

Peter

Well it was just bought from the store. In original packaging. And put into the unraid machine. So, I wouldn't think it was previously used.

 

I am currently following the piece of advice here: http://lime-technology.com/forum/index.php?topic=5384.msg84641#msg84641 and doing a low level format on it.

I'll update if that fixes it.

 

 

There has not been a "'low level format" command available for any modern disk drive for probably close to 20 years.  But, sice it is under way, might as well let it continue.  Only the first few sectors are probably needed to be zeroed, as those are the ones looked at by the OS when trying to determine its partitioning.

 

They are just writing zeros to the drive, same as you can with

dd if=/dev/zero count=8 of=/dev/sdX

(Just make sure you use the correct sdX device)

 

Joe L.

 

 

Thanks Guys.

 

Yeah I already started the LL Format. I would assume that the preclear script would be doing the same thing on the drive if I just let it tell me errors long enough

Once it finishes, I'll test it in the unraid machine. If I get no errors, at least I will know what it was.

 

Barring that, I'll run preclear on it, and see if it then seems to function correctly.

 

 

Irregardless of both of the above steps. I'll go to the unraid 4.7 beta 1 and unjumper it entirely and run the new preclear -A on it. Once I'm at that level the only further course of action I can take is to move to 4.7 final when it's out, correct? (can't go backwards once you've formatted it with the preclear -A?)

 

(can't go backwards once you've formatted it with the preclear -A?)

Not without some difficulty in re-locating the partition.

 

Joe L.

Low Level Format fixed this.

 

Will be moving it to unraid 4.7 as suggested.

 

Thanks