Western Digital GP drives and Unraid

Hi,

I have a 15 drive unraid 4.4.2 server which has a mixture of Western Digital EACS/EADS drives, Samsung HD103SJ drives and some smaller older seagate 7200rpm drives which im slowly replacing with 1tb's as money becomes available.

Since I built the server late last year I have noticed that when copying data to the EADS the copies are "peaky" in that it will copy at ~26MB/s then drop to ~5MB/s and keeps rising and falling like that through the whole transfer. End result is an average transfer to the drives of around ~15MB/s. When copying to the Samsung drives I get a constant throughput of ~28MB/s and there are no dips in copy speed. Comparison of network traffic when copying the data also examples this behaviour so its not a network issue otherwise i would be getting the spikes on the samsungs as well. It doesnt seem to matter what controller the drives are connected to either as I have some on an ICH10R controller and some on 2x1430SA cards on a Asus P5Q-Deluxe motherboard.

I've been reading heaps on these drives to try and find out what the discrepancy is between the two units. Both are 5400RPM green drives with 32MB of cache so theoretically should be identical in speed but there is an about a 5:3 advantage to the samsungs in average transfer speed. From what i read in these forums a lot of other users with the WD drives experience this peaky-ness to transfers so I eventually gave up trying to work out what the issue was and just accepted it as normal behaviour.

However the other day I stumbled on a thread (http://forums.whirlpool.net.au/forum-replies.cfm?t=1367904) in another forum which has made me start querying again and I've since discovered several other threads which I will link to at the bottom of this post reporting similar issues.

Basically in a nutshell the gist of the threads is that the green power drives use the "Intellipark" feature that parks the heads of the drive every 8 seconds of inactivity (at default). Thats fine for Windows and Mac based systems but there appears to be an issue with this and the way Linux I/O works. From what i've read (I dont know enough about linux to know if this is true, I'm a Windows guy at heart) Linux fills the buffer every 20 seconds when reading and writing to the drive. Because this is longer than the 8 sceonds delay of the intellipark "feature" the heads go off and park them selves in between buffer fills.

My question is this. I know unraid uses a lot of custom IO switches so I dont know if this 20 second delay is in unraid but could this be the cause of the peaky transfers on the WD GP drives? The drive is writing along and then the head parks while waiting for buffer to fill and then has to unpark the head to start writing again?

WD have a tool called WDIDLE3 that you can lengthen the delay or disable the feature entirely but I'm a little hesitant for fear of losing some of my data to try a tool that mucks around with my drives on such a low level before I gather any further information.

Has anyone else using unraid stumbled upon this (I couldnt find anything with the search facility) or used the WDIDLE3 program to "fix" said feature on the drives? Is this even an issue with unraid or is the peaky-ness of my GP drives associated to something else entirely? Hopefully someone with a bit more experience with the linux I/O system and GP drives can shed a bit of light on this?

More threads i've found are below (most are from NAS devices that use Linux as their OS):

http://groups.google.com/group/linux.kernel/browse_thread/thread/505ccf760023d132/7e4f4e996f911efd

http://forums.storagereview.com/index.php?showtopic=27269

http://tivocommunity.com/tivo-vb/showthread.php?t=370784&page=147

http://www.silentpcreview.com/forums/viewtopic.php?t=51401&postdays=0&postorder=asc&start=0&sid=32be05e3f407ba7da469440f3eb97630

http://www.readynas.com/forum/viewtopic.php?f=24&t=32179

http://forum.qnap.com/viewtopic.php?f=182&t=14273

gonna give this a bump to see if anyone has investigated this issue then i guess ill do the tweaks and report back..

However the other day I stumbled on a thread (http://forums.whirlpool.net.au/forum-replies.cfm?t=1367904) in another forum which has made me start querying again and I've since discovered several other threads which I will link to at the bottom of this post reporting similar issues.

 

Basically in a nutshell the gist of the threads is that the green power drives use the "Intellipark" feature that parks the heads of the drive every 8 seconds of inactivity (at default). Thats fine for Windows and Mac based systems but there appears to be an issue with this and the way Linux I/O works. From what i've read (I dont know enough about linux to know if this is true, I'm a Windows guy at heart) Linux fills the buffer every 20 seconds when reading and writing to the drive. Because this is longer than the 8 sceonds delay of the intellipark "feature" the heads go off and park them selves in between buffer fills.

My smartctl tool does not show any excessively high Load/Unload Cycle counts for my WD Green drives.

The links you gave above concern themselves with the way Linux pdflush threads work:

/proc/sys/vm/dirty_expire_centiseconds (default 3000): In hundredths of a second (30 seconds), how long data can be in the page cache before it's considered expired and must be written at the next opportunity.

In unRAID that value is set by default to 100 centiseconds (1 second). Therefore the 8 second WD Intellipark should not affect unRAID in any way.

Purko

When writing large files to unRAID, the disk is not pausing.

Once the unRAID kernel goes to 2.6.32, you should see the spikiness disappear.

Thanks for the replies guys...

My smartctl tool does not show any excessively high Load/Unload Cycle counts for my WD Green drives.

From what i've read in the threads posted above the load/unload cycle counts are not increased by this activity so thats not an indication of issue not presenting itself.

In unRAID that value is set by default to 100 centiseconds (1 second). Therefore the 8 second WD Intellipark should not affect unRAID in any way.

Thats good to know. At least I now know this issue isnt present in unraid.

Once the unRAID kernel goes to 2.6.32, you should see the spikiness disappear.

Any ideas on why the spikiness only exhibits itself on my WD GP drives but the Samsung equivalent green drives the throughput is constant? Whats different about the WD GP drives that makes them "spiky"? Just curious on this one if anyone knows. If I had of known this at the beginning of my journey I would have had all Samsungs...

When writing large files to unRAID, the disk is not pausing.

 

Once the unRAID kernel goes to 2.6.32, you should see the spikiness disappear.

 

Any idea when this might happen?    I'm getting ready to build an UnRAID server using the WD drives, so would like to bypass this issue altogether if waiting a bit before setting it all up will do so.

I've noticed the peaks and valleys in network when transferring large files (a few GBs) to my WD20EADS.  At first I thought it might have been Windows, but this thread is saying otherwise.  When transferring to my 1GB WD1001FADS (Black), I do not experience this peaks and valleys.  I don't think this issue exist when I transfer smaller files (a few hundred MB).