WD 2TB Black vs Green for Parity?


Recommended Posts

I apologize if this has been asked/answered before, I'm new to the forums and still trying to sift through all of the information on here.

 

I'm about to build my first unRAID production server using 4.7 final and three WD20EARS drives that I've already pre-cleared, aligned to sector 64 without jumpers.  I'm wondering if it would be beneficial for me to pickup a WD 2TB Black drive to use for parity to get better performance.

 

This server will be use for hosting my Blu-ray rips in MKV format that I stream to either a PopcornHour C-200 or WDTV Live Plus (one or the other, not both at the same time).  Each file is typically 20-35GB in size.

 

I'm using a MB & CPU from an old HP dc7600, it's got a 2.8GHz Pentium 4 with 1GB of PC5300 RAM, four onboard SATA ports, Gigabit Ethernet, one PCIe x16 slot, and one PCIe x1 slot.  PSU is some 400W unit that came in my Antec Nine Hundred case.  I plan to upgrade these components soon, especially the no-name PSU.

 

So, back to my main question, should I go with a WD 2TB Green EARS drive or a WD 2TB Black drive for my parity drive?  I appreciate any input on this.  Thanks!

Link to comment

unRAID will be as fast as your slowest disk involved. Having a faster parity drive than your data drives will be of no benefit unless you have multiple simultaneous writes occurring on your system to different drives. Since you have 3 EARS drives for data, unless you plan on writting to 2 of them at exactly the same time, having a faster parity drive will be of no benefit at all.

Link to comment

unRAID will be as fast as your slowest disk involved. Having a faster parity drive than your data drives will be of no benefit unless you have multiple simultaneous writes occurring on your system to different drives. Since you have 3 EARS drives for data, unless you plan on writting to 2 of them at exactly the same time, having a faster parity drive will be of no benefit at all.

 

Really, I did not know this. I was going to upgrade my wd ears drive to a wd black but now I may not

Link to comment

When I say unRAID is as fast as the slowest disk involved I mean the combination between the single data drive you're writing to and the parity drive that has to be updated.

 

If you have some 7200rpm data drives, then if you want higher performance on writes to those data drives then you should also have a 7200rpm parity drive.

Link to comment

What about failure rate? It's been my impression that the WB Caviar Black drives are more reliable than the Greens, and I'd think you'd want the parity drive to be the most reliable and have the least chance to fail. (And isn't it the one that is getting the most usage?)

Link to comment

I'd think you'd want the parity drive to be the most reliable and have the least chance to fail. (And isn't it the one that is getting the most usage?)

Wrong.  It is no more important, nor any less important than any other disk in the server. You need EVERY drive to be reliable in order to re-construct a failed drive. 

 

Also incorrect as far as usage... For many of us with large collections of movies, it is actually the drive with the least usage, since we write to the array very infrequently compared to the hours playing movies/music.

Link to comment

A faster parity drive can come into play in other areas, pre-clearing for example.  My WD Black 2TB pre-clears about 8 hours faster than my 2TB green drives.  Not that I do that every day, but even if I preclear twice a year, that is 16 saved hours.

 

Which I also use a mix of 5400 and 7200 rpm drives, so I want my parity drive to be the fastest drive in my system to cover anything I might throw at it, as I throw a pretty wide hodge podge of disks at it.  Just added flexibility if I ever need it.

 

I also frequently write to at least two drives, and sometimes three.  If you PC has two optical drives, you can run two instances of a ripping program and rip two disks at once to different drives.  Really speeds up the process of initially getting your library into unRAID.

 

Some people also use all green drives, and then later add a cache drive.  They want the cache drive to be fast to speed up transfers, and having a faster parity reduces the time it takes to dump your cache each day.

 

My personal experience is that a faster parity speeds up writes to the array, even when it involves a green data drive.  My initial unRAID build was a 1TB WD Blue (parity), 1TB WD Green (85 MB/s), and 1TB Samsung EcoGreen (88 MB/s).  With the 7200 rpm blue drive (average transfer of about 100 MB/s on HD Tune), I consistently got 22-24 MB/s overall write speed to the array.  My first upgrade was to add a 2TB 7200 rpm Hitachi as parity (HD Tune average of 125 MB/s).  The WD blue went into a fourth bay and my green drives stayed as is.  My write speed to those green drives is now consistently 26-28 MB/s (34 MB/s to the blue).  The only change was the parity drive.

 

So my experience differs from what is being stated, as a switch in parity drive did boost my write speeds when Green drives were involved.  Some bottleneck was removed (transfer speeds, buffer size/speed, something).

Link to comment

Was no other part of your system changed at all, it was identical unRAID versions with identical ram and cpu and using identical SATA ports? If so, then it's something to note.

 

Just for reference, my pure Green (5400/5900rpm) system has writes of 30-34 MB/s when dealing with 10GB or larger, but then again it's on a Slackware Current distro with newer Linux kernel (2.6.37). It has drastically improved since my early days with unRAID 4.4 / unRAID 4.5 beta 1.

Link to comment

Was no other part of your system changed at all, it was identical unRAID versions with identical ram and cpu and using identical SATA ports? If so, then it's something to note.

 

Just for reference, my pure Green (5400/5900rpm) system has writes of 30-34 MB/s when dealing with 10GB or larger, but then again it's on a Slackware Current distro with newer Linux kernel (2.6.37). It has drastically improved since my early days with unRAID 4.4 / unRAID 4.5 beta 1.

 

I'm still on unRAID 4.5 final.  Hopefully newer versions of unRAID will give me a performance boost.  I don't typically run 10GB and larger files.  I'm still in the process of ripping 800 DVD movies/TV shows (so well over a thousand discs with the TV sets).  Then I'll start on BD's.  So my files typically seem to be 3-5 MB for the movies, and 1-2 GB for the TV episodes (ripped individually).

 

As for my hardware, everything stayed the same.  I built the system and installed 2 3-in-2 drive cages.  The only thing that changed on it was that after I went over four drives (my MB had 4 SATA ports), I added a Supermicro to run additional drives.

 

My theory is that it has something to do with network transfers.  In theory, if all your HDD's share a bus.  One bit would be read from Storage Drive A.  It would be written straight to storage drive B.  Then it is read from storage drive B, processed by unRAID, and the answer written to the parity drive.  If you look at that bit-by-bit at a time, in theory, nothing should happen faster than the slowest drive.  It is a stream of data and the slowest drive determines how fast the stream can flow.

 

However, copying across a network, data is sent in transmission packets (which can very in size depending on the network).  So while packets are small, they still aren't bit by bit.  So if you go to the far end of the spectrum, if Storage Drive A read 85 MB/s, Storage drive B wrote and read 85 MB/s, and your parity drive wrote at 85 MB/s.  If you sent an 85 MB packet, drive A would transmit that packet, drive B would receive it.  Drive A would not transmit the second packet till Drive B had successfully received the first.  The unRAID wouldn't read Drive B until the entire packet had been received, and likewise, parity wouldn't write it until the entire packet had been read.  So with an 85 MB packet, it would take 4 seconds.  But if your parity drive were faster, it would take less time.  (I realize this packet size is extremely exaggerated, but its just to get the concept across).

 

However, since Drive B and the parity drive are on the same bus, you would think it would be a packet transfer between A and B, and bit-by bit between B and Parity.  So my theory is the packet nature between A and B is also carried through B and parity.  SO it isn't one bit out, one bit in.  But it is a small packet, so you do gain some speed their when reading from the data drive to parity.  The parity drive waits for an even to complete on the data drive, then reads and writes a burst of data.

 

But its just a wild theory to explain why I see faster transfers with a faster parity drive.  I don't know enough about the inner workings of unRAID to know if the theory is valid or not.  Is the data transfer most like a stream, or is it a series of bursts?  With a stream, I don't know there would be an advantage to having faster parity, but with a burst, I could see it.

Link to comment

I would think the faster parity drive would speed up writes, even to a single disk. Here is why. Since unRAID only spins up the disk being written to and the parity disk on writes, I presume that in order to calculate the parity change, it has to read the bit from parity in parallel with writing the bit to data, but then the parity disk has to make a full revolution before that bit can be written.

 

I could be mistaken however.

Link to comment

Nice thought, but no.

 

You still have to wait for the slowest drive to do the read of the old data before you can calculate the new parity. You still have to wait for the slowest drive to do it's 1 rotation back to the sector to be written in order to do the write. The entire write operation is still bound by the slowest drive (parity and data).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.