Skip to content
View in the app

A better way to browse. Learn more.

Unraid

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Trouble with WD15EACS 1.5 TB drives.

Featured Replies

Hi all; I recently purchased 2 of the new WD 1.5TB Green drives with plans to upgrade some of my NAS storage.  I'm running unRAID 4.3 beta 6.  Before starting the upgrade I had 13 drives installed in the system, 11 SATA disks and 2 PATA disks.  The parity drive was a 1TB WD10EACS.  I actually have 6 of the WD10EACS installed (including the parity drive) and have never had any problems with them, so I figured the WD15EACS drives would be no-brainers.  For the record, the PS is a Corsair TX650 with a single (massive) 12v rail which delivers something like 60 amps at its max.

 

The plan was to shuffle things around until I had eliminated the 2 PATA drives and I was left with a SATA only system.  I'm currently using 2 of the Promise 8 channel SATA controllers.  I started by swapping out the 1TB parity drive for a 1.5 TB drive.  This seemed to work ok.  Then I took out the smaller of the 2 PATA drives (the PATA drives were 200GB and 500GB) and replaced it with the old 1TB parity drive.  During the parity rebuild, the system became unresponsive on the network and was acting very strangely on the console.  Commands would hang for really long periods of time, but changing to another virtual terminal and back again seemed to unstick things.  I eventually had to simply power down the system and reboot it in order to recover some control.

 

At this point, because of the time it takes (30+hrs) I wanted to avoid two parity rebuilds.  Since I was just shuffling things around, I figured that I would just pull the other PATA drive from the array and replace it with the 1.5TB SATA drive right now.  The theory is that I could just telnet in, mount the old drive independently and copy the data over to the new drive (once the parity sync had completed).

 

I started this process, but this time with a lot more monitoring in place as I did so.  The process hung again, but not the same way as before.  I was watching all of the transfer rates using iostat when I refreshed the web page to check what the  percentage complete was.  As soon as I hit refresh, all the transfer rates went to zero and didn't resume.  Checking dmesg showed that the parity drive had suffered write errors.  smartctl refused to return any status for the device.  I had to shut-down and reboot to recover.  When I rebooted the BIOS initially didn't recognize the new parity drive, but on a subsequent reboot the drive showed up.

 

At this point in time, I figured I would leave the parity drive alone for now and just try to copy the data from my old 500GB PATA drive to the other new 1.5 TB SATA drive, and then rebuild the parity when it was finished.  I started this process, and by morning it had failed.  Once again the new 1.5TB drive (the second of the two drives) had suffered a write error/io error according to dmesg.  The file system mount-point had become read-only, and every time you tried to do an ls, you got an io error.  smartctl for the device was unresponsive again and a shutdown/reboot was required.

 

After the reboot, the first 1.5TB drive could no longer be recognized by the BIOS.  No matter what I did, I couldn't bring it back.  I connected it to different ports on each of the promise controllers as well as the motherboard SATA ports and none would recognize it.  After each failure, I would try the other 1.5TB drive on the same port, and it always succeeded.  Because of this, I started the RMA process with newegg to get the first (now bricked) 1.5 TB drive replaced.

 

Now running without a parity drive of any form installed, I tried to do the 500GB -> 1.5TB transfer again.  Again it failed in an almost identical fashion.  I am at work now, but I can collect specific error messages from dmesg when I get home tonight if people want to see them.

 

Here are my questions.

1) Should I try upgrading to unRAID 4.4?  I don't know much about the diffs, but if there have been patches to the SATA drivers or to the RAID driver between the two versions, I figure it might have some effect.

2) Is anyone else using the WD15EACS drives in their system and how well are they working?

3) Should be getting these drives replaced or are they all just junk and I should go back to 1.0TB drives (or to Seagate 1.5 TB drives)?

 

thanks in advance for all the help.

 

-john

1) Should I try upgrading to unRAID 4.4?  I don't know much about the diffs, but if there have been patches to the SATA drivers or to the RAID driver between the two versions, I figure it might have some effect.

 

I do like the improvements in the SATA support with each of the kernel releases, so I would recommend jumping over v4.4, all the way to the latest beta of unRAID, v4.5-beta4.  There have been small problems along the way, and it IS a beta, but is running solid for everyone I know.  Plus, the problems that have been found have in no way endangered data.  They have mostly been in newly added features not working perfectly.

 

Of course, no guarantees that it will fix the problems with those drives.  Your report sounds an awful lot like the early reports of the Seagate 1.5TB drive users, before their firmware fixes.  Brand new technology will always be 'bleeding edge'.  Same caution should also go to those purchasing the 2TB drives.

I might suggest looking for a BIOS update.  Sometimes old BIOSes have issues with new (large) disks.

 

You might also consider putting the new drives on different controllers (preference would be to put them on the motherboard ports, but if that gives problems try it on a Promise controller ports).  If the problems go away on one controller, you know that the drives are not defective.

 

If the problem persists with the newest BIOS and either controler, I would endeaver to run a smartctl report on each of those drives.  That should tell, once and for all, if the drives are bad.  (Follow the troubleshooting link in my sig for instructions on running smartctl).

Archived

This topic is now archived and is closed to further replies.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.