WD 1TB drives - Anyone with one to offer feedback?

[flambot]

About to buy my first 1tb drive - been using 750gb WD AAKS range (and SG500's), but the new WD is not this some range so aren't exactly rushing out to grab one yet - especially as the spin speed varies if I read the literature correctly - and I have to replace the parity drive, so wanted something that is not challenged (not sure it will be tho).  I like the idea of only 4w at spin down. 

 

Let us know if there is any feedback. - thx again.

[bubbaQ]

They are not 4 Watts at spindown.. they are 0.3 Watts at spindown!  They are 4 Watts at "idle."

 

I have two, and I love them.  They are all I will buy in the future.  Ultra quiet, and run several degrees cooler then their siblings in the drive same cage.  You may see some slight differences in benchmarks, there isn't much difference in practical application, particularly when the disk is much faster than the Ethernet connection.

 

On my base system with one data disk and parity disk, was under 300 minutes for full 1TB parity check.

[flambot]

They are not 4 Watts at spindown.. they are 0.3 Watts at spindown!  They are 4 Watts at "idle."

 

I have two, and I love them.  They are all I will buy in the future.  Ultra quiet, and run several degrees cooler then their siblings in the drive same cage.  You may see some slight differences in benchmarks, there isn't much difference in practical application, particularly when the disk is much faster than the Ethernet connection.

 

On my base system with one data disk and parity disk, was under 300 minutes for full 1TB parity check.

 

Thx for the input - and the correct specs - I was relying on my memory   

 

Are you saying in practical application there is no difference between this drive and say a seagate SATA as far as parity calculation speed?  I read somewhere (a comment in some post) that the drives variable rpm could affect read/write speed.  I guess what I didn't want was to buy a drive and find it didn't perform as well as the current system.  At the end of the day I guess one makes a decision and takes the chance.  The other factor is reading a few comments that the "Caviar" range isn't as robust as some of WD's other models.  More pondering...

[bubbaQ]

RAID stands for a Redundant Array of Inexpensive Disks (a/k/a Redundant Array of Independent Drives, but both are used).

 

Every drive will fail.  That is what backups and RAID are all about.

 

If you want to compare the Green WD drive to a Seagate's Barracuda ES.2, of course the Seagate turns in better benchmarks.  See http://www.storagereview.com/1000.sr?page=0%2C0  It costs 38% more than the WD, and has about 20% better performance in sequential data tests. But does that benchmark difference translate into real-world difference that is worth paying for?

 

Both drives have a *minimum* sequential benchmark of over 40 MBytes/sec (42 for the WD and 53 for the Seagate.  They max out at 80 and 105 MB/sec respectively).  The minimum performance of either drive is better than the best performance you can get out of Gigabit Etherrnet.  A difference in read performance over Ethernet will not be perceptible.

 

My test system did a full parity check on 2 WD Green 1TB drives in under 300 minutes (55MB/sec).  My fully loaded production system with 8 drives, some of them slow older drives, it took 700 minutes to sync a full 6 TB array.  Now would it be nice to shave 20 percent off that time?  Sure.  Would I complain if it took 20% longer?  Nope.

 

Say copying a 10GB disk image to unRAID takes 10 minutes.  Would I cry if it was 12 minuted instead?  No.  Am I willing to pay the premium price for that marginal increase in speed?  Not today.  When I have to write a large file, I start the copy, and then go about doing other things.  I multitask.

 

Writing is more complicated.  When you write a file to unRAID, after data is written, the daemon has to re-read the data, then read the appropriate sector on the parity disk, then rewrite to the parity disk.  So one write by you results in two reads and two writes by unRAID.  That's a lot of work for the disks.

In the write process, the data disk is a write, then a read.... so potentially it can benefit from cache... but I don't know if Tom has forced a write-thru for data integrity reasons.  (If so, it would be a nice configuration item to be able to disable it!)  The parity drive is read, they write the same sector back with modified data.

 

If speed is a high priority for someone, they should look at a traditional striped RAID which will run circles around unRAID in speed.  Be prepared to sacrifice money and flexibility.

 

I use unRAID for serving up sequential access to large files (media, Encase images, large (800MB) Photoshop images).  Write once, read many times, keep as archive.  So write performance is not nearly as important to me as read performance and data protection, and as I said earlier, read performance of both drives exceeds Ethernet, so it makes no difference to me.  The cooler, lower power, quieter, and better price point of the WD Green drives carries the day for me.

 

Oh, and BTW, the drive dies *not* have a variable RPM.  It is 5400 RPM.  The *family* of drives have different speeds, but each drive runs at one and only one speed.  The physics of a variable speed hard drive would be practically impossible in a conventional desktop drive of any decent performance level.

[flambot]

Thx for the in-depth reply. My application is similar - more reading than writing (being a media server only) - and realising the network connection is the bottleneck helps.  I also set-up the write function and walk away - and now that my collection is finally backed up, the writing portion tends to be less.

 

Being a noob in most things puter, I'm usually a little hesitant on the introduction of new stuff.  You get a feeling (affinity) with your current tech and making a change creates (well usually) increased concern.  This is further increased by the mini-rebuild I'm about to undertake - bigger PSU, 1TB parity replacement, addition of another drive.  I'll get there

 

The WD 1tb sounds like it will do the job I want and the lower power usage means a lot.  Now to decide on size/brand of PSU I should use 

 

Again, I appreciate the response.

[bubbaQ]

Without a doubt, the Antec Earthwatts 380.

 

[Joe L.]

RAID stands for a Redundant Array of Inexpensive Disks (a/k/a Redundant Array of Independent Drives, but both are used).

 

Every drive will fail.  That is what backups and RAID are all about.

It is said there are only two kinds of hard disks in the world, those that have already crashed/failed, and those that have not yet crashed/failed. It is only a matter of time. 

Writing is more complicated.  When you write a file to unRAID, after data is written, the daemon has to re-read the data, then read the appropriate sector on the parity disk, then rewrite to the parity disk.  So one write by you results in two reads and two writes by unRAID.  That's a lot of work for the disks.

True Writing is complicated.

In the write process, the data disk is a write, then a read.... so potentially it can benefit from cache... but I don't know if Tom has forced a write-thru for data integrity reasons.  (If so, it would be a nice configuration item to be able to disable it!)  The parity drive is read, they write the same sector back with modified data.

I'm pretty sure you are mistaken about the order of operations on the data disks.  For both the data disk AND the parity disk it is necessary to read the current content of a disk block before writing.  It makes no sense to write and then read the contents of what was just written.

 

So, unRaid has to first get the old contents of both the data drive and the parity drive.  Then, it bitwise compares the old and new data.  If for a given bit position on the data drive the value changes, from a zero to a one, or from a one to a zero, then that corresponding bit on the parity drive also needs to be "flipped from its current value to the opposite" If the parity bit is a one, make it a zero, if a zero, make it a one.  So, we need to know the current value of the data AND parity before we write the new. Once that math is done on the full block of data the parity AND data drives can be written.

 

If a given bit on the old and new data does not change, that corresponding bit on the parity drive does not need to change.

 

So, we can issue the read requests in parallel to both the data drive and the parity drive.  We can then do all the bitwise comparisons in memory to figure out the new parity block to be written.  We can then issue both write requests to the disks in parallel.

 

The basic issue is disk speed, or how long we have to wait after reading a block from a disk before that same block passes under the disk heads again to be written.  If the parity calc took no time at all we still need to wait for a complete rotation of the disk after reading it before we can write to it.  Yes, its internal buffer will deal with small bursts of activity, but when writing multiple gigs, the 16Meg cache does not do too much to help. Most times, it is read cache. (Not sure if it is ever used when writing0

 

So, faster 7200 RPM disks will take at least .00833 seconds to read or write a single block.  It has to, since it will take that  long to rotate once. And that is if their controller can keep up.  To write the next sequential block might require a full cylinder rotation to get into the position to read, and then another to write.  If timing is not perfect it will take longer.  I'm guessing writing two blocks in succession will take 5 or more rotations of the disk and could take nearly 10 rotations if you had to initially wait nearly a full rotation before writing and/or reading..

 

A conventional RAID array striped across disks would have NO speed advantage over unRaid when writing a single block.  If each stripe is one block wide,  then when writing two contiguous blocks conventional RAID would have two reads and two writes to each of two drives.  (It could do all four reads in parallel, and all four writes in parallel)  This reading and writing of multiple data and parity drives in parallel is where striping data results in performance improvements)

[bubbaQ]

It makes no sense to write and then read the contents of what was just written.

 

Sure it does.  In high-integrity applications or low-confidence write operations, each disk write is followed by a disk read while the original data is still in memory, to compare what was written with what was read to ensure data was written w/o error.  Ever use the write verify flag in DOS?  It is much less needed today with error correcting drives, but it is still used in some special applications, and in other disk technologies... don't you do a verify pass after burning a CD/DVD?

 

So, unRaid has to first get the old contents of both the data drive and the parity drive.  Then, it bitwise compares the old and new data.

 

You are correct... I had a brain fart on that one.  I plead a caffeine shortage.

 

the 16Meg cache does not do too much to help. Most times, it is read cache. (Not sure if it is ever used when writing)

 

Actually, the 16M cache is very useful in writing, even very large files, with features like command queuing, reordering the writes to be more efficient based on which sectors are writable first (which flattens out performance perturbations dues to that would occur "waiting" for the correct sectors to spin into place).

 

So, faster 7200 RPM disks will take at least .00833 seconds to read or write a single block.  It has to, since it will take that  long to rotate once.

 

Depends if disk I/O is based on blocks, clusters, cylinders, sectors, etc.

 

To write the next sequential block might require a full cylinder rotation to get into the position to read, and then another to write.  If timing is not perfect it will take longer.  I'm guessing writing two blocks in succession will take 5 or more rotations of the disk and could take nearly 10 rotations if you had to initially wait nearly a full rotation before writing and/or reading.

 

Not always.  Depends on number of heads too, and the physical (as opposed to logical) arrangement of data.  You see a slower spinning drive can actually write *faster* in certain circumstances -- particularly in an unRAID environment where reads are followed by re-writes of the same block of data with some calculation time in between the disk IO operations. If you read a block, then do parity calc, and are ready to re-write the changed block, the faster spinning drive could have spun past the start point and you have to wait for a rotation, whereas the slower drive could be optimality positioned to immediately begin the write.  Depends on the length of time to do the processing to be ready to write.  This is why the 16MB of cache can make a significant contribution to performance in writing even very large files.  Similar to varying the interleaving to improve performance when the disk could "outspin" the data rate of the drive.

 

A conventional RAID array striped across disks would have NO speed advantage over unRaid when writing a single block.  If each stripe is one block wide,  then when writing two contiguous blocks conventional RAID would have two reads and two writes to each of two drives.  (It could do all four reads in parallel, and all four writes in parallel)  This reading and writing of multiple data and parity drives in parallel is where striping data results in performance improvements)

 

Apples and oranges.  In that example of a single block, the entire operation would fit in the drive cache so drive physical performance is moot.  Plus in  most striped RAID implementations, you don't read the old data to compare it to the new to get parity -- parity is calculated from the new data only, and written w/o any reading so it will beat unRAID in write performance in writing data of any size, including your 1-block example.  In a more realistic scenario for users with media files, with a striped RAID with 4 data disks and one parity, when you write a 4 GB file, the entire 4GB is written in the time it takes the slowest drive to write 1 GB because all 5 disks are writing in parallel their own 1GB portion of the 4GB file.

[Joe L.]

It makes no sense to write and then read the contents of what was just written.

 

Sure it does.  In high-integrity applications or low-confidence write operations, each disk write is followed by a disk read while the original data is still in memory, to compare what was written with what was read to ensure data was written w/o error.  Ever use the write verify flag in DOS?  It is much less needed today with error correcting drives, but it is still used in some special applications, and in other disk technologies... don't you do a verify pass after burning a CD/DVD?

Yes, I do a verify pass when burning CDs... but I was talking in terms of unRaid... it would have no reason to subsequently read the written data it had just written unless it had a high-reliability mode that could be invoked, and it does not today perform a subsequent read verify. (it would slow it down even more and would somehow need to bypass any/all of the cache to ensure the OS and the disk did not simply return the block from their in-memory copies.) 

So, unRaid has to first get the old contents of both the data drive and the parity drive.  Then, it bitwise compares the old and new data.

 

You are correct... I had a brain fart on that one.  I plead a caffeine shortage.

 

the 16Meg cache does not do too much to help. Most times, it is read cache. (Not sure if it is ever used when writing)

 

Actually, the 16M cache is very useful in writing, even very large files, with features like command queuing, reordering the writes to be more efficient based on which sectors are writable first (which flattens out performance perturbations dues to that would occur "waiting" for the correct sectors to spin into place).

 

So, faster 7200 RPM disks will take at least .00833 seconds to read or write a single block.  It has to, since it will take that  long to rotate once.

 

Depends if disk I/O is based on blocks, clusters, cylinders, sectors, etc.

 

To write the next sequential block might require a full cylinder rotation to get into the position to read, and then another to write.  If timing is not perfect it will take longer.  I'm guessing writing two blocks in succession will take 5 or more rotations of the disk and could take nearly 10 rotations if you had to initially wait nearly a full rotation before writing and/or reading.

 

Not always.  Depends on number of heads too, and the physical (as opposed to logical) arrangement of data.  You see a slower spinning drive can actually write *faster* in certain circumstances -- particularly in an unRAID environment where reads are followed by re-writes of the same block of data with some calculation time in between the disk IO operations. If you read a block, then do parity calc, and are ready to re-write the changed block, the faster spinning drive could have spun past the start point and you have to wait for a rotation, whereas the slower drive could be optimality positioned to immediately begin the write.  Depends on the length of time to do the processing to be ready to write.  This is why the 16MB of cache can make a significant contribution to performance in writing even very large files.  Similar to varying the interleaving to improve performance when the disk could "outspin" the data rate of the drive.

You made the exact same point I did, but I did not clearly say what I was trying to say. (I'll blame caffene excess )

A disk read of a single bit, followed by a disk write of that same single bit must take at least one rotation of the disk platter, regardless of how it is organized in sectors, blocks, cylinders. Basically, that bit passed under the read head once and we must wait untill it is under the head again for writing.  Since a single head is involved for the one bit, we have to rotate the disk platters all the way around.  Now, as you said, if parity can be calculated in-between the read and the write in the time it takes the disk to rotate once, it is great!.  It the parity calc takes longer than one rotation time, then we might have to wait another full rotation to be able to write the desired bit.

A conventional RAID array striped across disks would have NO speed advantage over unRaid when writing a single block.  If each stripe is one block wide,  then when writing two contiguous blocks conventional RAID would have two reads and two writes to each of two drives.  (It could do all four reads in parallel, and all four writes in parallel)  This reading and writing of multiple data and parity drives in parallel is where striping data results in performance improvements)

 

Apples and oranges.  In that example of a single block, the entire operation would fit in the drive cache so drive physical performance is moot.  Plus in  most striped RAID implementations, you don't read the old data to compare it to the new to get parity -- parity is calculated from the new data only, and written w/o any reading so it will beat unRAID in write performance in writing data of any size, including your 1-block example.  In a more realistic scenario for users with media files, with a striped RAID with 4 data disks and one parity, when you write a 4 GB file, the entire 4GB is written in the time it takes the slowest drive to write 1 GB because all 5 disks are writing in parallel their own 1GB portion of the 4GB file.

You are correct here.  I did not consider the situation where we are writing 4 blocks of data AND their parity, and that the striping could put one block of data on each physical disk (in the same position on each disk) and not do any reads since in memory it would already have the data to calculate parity for that set of blocks.  Not having to read and then write would obviously save time... as would parallel writes to multiple drives, each with 1/4 of the data.    I''ll concede, writing large media files (large number of blocks of data) could be way faster...

 

The challenge is to interleave the reading, parity calculation, and writing in unRaid so that performance is optimal.  We can see the effects of the current implementation in the start-stop flow across the network.  Once we start writing to a disk, the disk buffer pool is quickly filled, then, currently, the process of emptying it (writing to the physical disks by bdflush) is taking a higher priority than the networking.  This results in uneven (sporadic 80-90% utilization, then 0%, then 80-90%, etc.) network traffic flow.

 

Now, to get slightly back on topic in this thread, the 1TB drives should be able to hold 25% more data than the older 750Gig drives  I do love the idea of using less energy to spin the drive.  Just need to find a good 1Tb drive sale.

 

Joe L.

[bubbaQ]

Now, to get slightly back on topic in this thread

 

Agreed! 

 

Look for the Western Digital My Book Essential USB 2.0 External Hard Drive model WDH1U10000N.  It has the 1TB Green drive inside, and thats how I got both of mine.  Amazingly, I have found that puppy for $200, while the best price I've found on the bare drive is $250.  Check this thread on FatWallet:  http://www.fatwallet.com/t/18/790554 .  There is a trick to opening the suckers up... you have to remove the rubber feet, and insert a small screwdriver to release 2 tabs, then it will open up easily.

 

One small nit... a 1TB drive has 33.3% more capacity than a 750GB drive... not 25% 

 

 

[goofygrin]

On my base system with one data disk and parity disk, was under 300 minutes for full 1TB parity check.

 

Just for comparison, my unRAID with 6 1TB hitachi 7200RPM drives takes right around 300 minutes to do a full parity check (4 are on the onboard controller and 2 on a promisa SATA300 card).

[BLKMGK]

Running three of these drives myself - quiet and they seem just as fast. However WD's warranty is shorter than Seagate's and that gives me pause. I do very much appreciate that it uses less power though! I'm now in need of more space and drives haven't been going on sale much so I'll have to look for those enclosures! Need more activity in the deals forum guys! 

 

P.S. Some of the new Seagate drives - gen II drives - are coming with 32meg of buffer. I went ahead and spent a little more for one of those guys (750gig) although frankly mixed in with all the others any performance increase is lost on me. Personally I think big cache sizes is a nice trend, anything to bump performance without noise and faster spindle speeds is fine by me.