I needed to expand my array a few weeks back and took the opportunity to plug in a new WD Red 6TB drive as a parity drive (aka disk0, sdc) and use the old 4TB parity drive to expand the array.  The 6TB drive passed 2 passes of preclear and parity rebuilt successfully (all of which takes pretty much a solid week to accomplish, btw), but the first time the mover ran the new parity drive comes up with a ton of read errors and gets red-balled.

 

So I RMA'd that drive and bought another WD Red 6TB drive from a different vendor. Just had the same thing happen again! Two preclear passes and rebuilt successfully, red-balls the first time mover ran.

 

I'd appreciate some sets of eyes on the attached log, see if anybody sees anything that might suggest something other than another bad disk.  Things start going south around line 1866.  Unraid Pro 5.0. I haven't found anything on the boards suggesting problems with these 6TB drives, but I think I'm going to go back to 4TBs.

 

Thanks in advance for your help.

 

--Jim

syslog.zip

Try setting the WD 6Tb disk to not spin down.

 

On both mine and my brother's Unraid systems we have found that there appears to be an issue with WD 6Tb drives that they sometimes appear to have issues restarting after they have spun down;  which is just what is likely to occur when mover starts overnight.

 

Setting our 6Tb disks to not spin down appears to have solved the issue for us.  It would be interesting to see if the same goes for you.

Interesting!  From looking at the full syslog (I edited the mover log out of what I posted), I know the parity disk was in fact spun down when the mover started, and the disk started acting up 46 seconds and 6 files into the move. (Due to buffering could have been earlier).

 

If the disk successfully makes it through a rebuild of parity, that will be some evidence that the spin-up could have something to do with it.  I'll keep the disk spun up for a few mover cycles after that.  If it holds together, I will look into having the mover gracefully spin up and exercise the disks before actually writing anything.  That strikes me as preferable to leaving the disk spinning permanently.

 

Thanks!

 

--Jim

So after disabling the spin-down, another ~28 million successful writes in the parity rebuild, and some successful moves I'm ready to believe this has something do with a unique low-power behavior of the WD Red 6T drive.  I'm doing a parity check now to get some reads into the mix, but the next thing to do is add some lines to the mover script to force the parity drive to spin up and stabilize before the moves begin.  Unfortunately, that won't be until after I get another 6T drive for parity so I can keep this one as backup, just in case.

 

How do we bring this to the attention of the powers-that-be who can decide what if anything unRAID needs to do to cope with this situation?  It's not really an unRAID bug in the classic sense, but on the other hand it's easy to foresee a lot of users moving to these new drives so this has the potential of becoming a common occurrence.

Im using 5 x 6TB WD Reds and I have had no issues with any of my drives. I don't use a cache drive though. I have a friend who used one on his 6TB drives and he removed it as he said it really made very little difference in write speeds. Are you using a SSD for the cache drive and have you tried it without?

Just adding my experience, I have a 7 disk array where there are 4 6Tb HDDs (one of which is parity) and three older 3TB WD Green HDDs (but without a cache disk). I have not encountered any problems of this type.

megalodon, papnikol -

 

I appreciate the both of you taking the time to provide your input. Based on my experience so far, I am not surprised that the issue would not occur in a configuration without a cache drive. Without a cache drive, there is no mover to start up when the disks are in a low-power state. When adding a file to the array, the drives are almost certainly already spinning as a result of navigating to a destination directory in the array to receive the new files. (I imagine there might be techniques to add files that wouldn't necessarily spin up the drives first, but none come to mind.  Certainly nothing I would do routinely.).

 

I too have heard that a cache drive doesn't really improve performance.  I originally set my system up with a 7200-RPM cache drive and 5400-RPM data drives, but don't really get anything out of the cache as I am limited by the speed of my network. I wonder if that will remain true as we move into the age of ultra fast ethernet (10 Gb soon, 40 Gb not that far off). I plan on doing some remodeling next year and have been seriously considering pulling some Cat 7 cable while I have the chance.  Those who move BD-sized data around routinely may start finding it worthwhile to have a super-fast cache drive.

 

But for now, I tend to agree with you. Removing the cache drive would be another workable solution and one that comes without much (if any) performance penalty.

 

--Jim

There are many posts on this forum that state it was really designed in the older days of unRAID with slower network speeds and is really not worth the hassle nowadays with more modern hardware. I have a friend who always goes on about the speed of his 10 bay qnap and today when running tests he only achieved 10mb/s more than my unRAID server which to me is nothing. I let a file copy and do other things. If speed over the network if a concern then maybe a cache drive would help. Im sure some of the more experienced long tern users can comment on if it really makes much difference. Maybe on a SSD drive it will but probably not much on a mechanical drive.

Also my 6TB's don't spin up when navigating the folders as cache dirs takes care of that. The drive that is being written to spins up once I start the copy process over the network as there is a delay while it spins up the drive before the file starts copying.

Remember one more thing when copying directly to the array.  If you have enough memory in your server, the excess memory is used for a write cache when the copy first starts.  This buffering could easily be providing enough time for a slow drive to come available for the actual physical write. 

 

I also have the feeling that WD considered (when they were designing these drives) that they would be using in large RAID arrays and would probably never be spun down.  As a result, they did not give much consideration to the time required for them to come up to speed.

Thats interesting Frank1940, I wonder then if the excess memory is also used as a buffer cache when reading a movie. I seem to remember manually spinning down my drives once and the movie carried on playing for a few minutes after.

Thats interesting Frank1940, I wonder then if the excess memory is also used as a buffer cache when reading a movie. I seem to remember manually spinning down my drives once and the movie carried on playing for a few minutes after.

 

Yes, I have observed the same thing.  (I have noticed it when I pause a movie long enough that unRAID spins the drive down.)  However, I suspect that my media players (Netgear NeoTV-550) also have some cache installed on them because the data arrives at the media player in bursts and the burst spacing often varies widely depending on network conditions.  (I am thinking of the Internet as the prime example here.) So I don't know quite where the caching might be occurring.  It might be in both places...

Im using openelec on an intel NUC, I do think its unRAID however because before when I setup a NUC for a friend who used a different software RAID server. I had to wait for the drives to spin up, i.e. buffering in OpenELEC before the movie played after a long time pausing. I think it was flexraid.

Im using openelec on an intel NUC, I do think its unRAID however because before when I setup a NUC for a friend who used a different software RAID server. I had to wait for the drives to spin up, i.e. buffering in OpenELEC before the movie played after a long time pausing. I think it was flexraid.

 

There definitely should be some client buffering involved as well. I know if I am watching media via WMC from another computer and the disk has spun down while the video is paused that it will usually still play for a few seconds before pausing to let the disk catch up. I don't know if this is the case in every scenario, but is likely fairly common as it will allow the media player to buffer against network hiccups or other issues.

Yes you may well be correct as this would make perfect sense to me, it plays for quite a long while but I can't remember if it then buffers after.