WD Red Pro Review: 4 TB Drives for NAS Systems Benchmarked
by Ganesh T S on August 8, 2014 9:00 AM EST
Introduction and Testbed Setup
A couple of weeks back, Western Digital updated their NAS-specific drive lineup with 5 and 6 TB Red drives. In addition, 7200 RPM Red Pro models with 2 - 4 TB capacities were also introduced. We have already looked at the performance of the WD Red, and it now time for us to take the WD Red Pro for a spin. In our 4 TB NAS drive roundup from last year, we also indicated that efforts would be taken to add more drives to the mix along with an updated benchmarking scheme involving RAID-5 volumes. The Red Pro gives us an opportunity to present results from the evaluation of various drives that have arrived in our labs since then.
The SMB / SOHO / consumer NAS market has been experiencing rapid growth over the last few years. With declining PC sales and increase in affordability of SSDs, hard drive vendors have scrambled to make up for the deficit and increase revenue by targeting the NAS market. The good news is that the growth is expected to accelerate in the near future (thanks to increasing amounts of user-generated data through the usage of mobile devices). In addition, security threats such as SynoLocker have also underscored the necessity of frequent backups.
Back in July 2012, Western Digital began the trend of hard drive manufacturers bringing out dedicated units for the burgeoning SOHO / consumer NAS market with the 3.5" Red hard drive lineup. The firmware was tuned for 24x7 operation in SOHO and consumer NAS units. 1 TB, 2 TB and 3 TB versions were made available at launch. Later, Seagate also jumped into the fray with a hard drive series carrying similar firmware features. Over the last two years, the vendors have been optimizing the firmware features as well as increasing the capacities. On the enterprise side, hard drive vendors have been supplying different models for different applications, but all of them are quite suitable for 24x7 NAS usage. While mission-critical applications tend to use SAS drives, it is the nearline SATA versions that are more suitable for home / SMB users. These enterprise drives provide better reliability / longer warranties compared to the NAS-specific WD Red and the Seagate NAS HDD lineups.
The correct choice of hard drives for a NAS system is influenced by a number of factors. These include expected workloads, performance requirements and power consumption restrictions, amongst others. In this review, we will discuss some of these aspects while evaluating ten different hard drives targeting the NAS market. One of the most glaring omissions in our list is HGST's Deskstar NAS. Due to HGST's strange sampling scheme, we are still trying to obtain enough drives for our NAS-specific benchmkaring, but they did send us their 4 TB SAS drive for participation in this roundup. Other than the HGST SAS drive, the other nine drives all carry a SATA interface.
- WD Red Pro (WD4001FFSX-68JNUN0)
- Seagate Enterprise Capacity 3.5" HDD v4 (ST4000NM0024-1HT178)
- WD Red (WD40EFRX-68WT0N0)
- Seagate NAS HDD (ST4000VN000-1H4168)
- WD Se (WD4000F9YZ-09N20L0)
- Seagate Terascale (ST4000NC000-1FR168)
- WD Re (WD4000FYYZ-01UL1B0)
- Seagate Constellation ES.3 (ST4000NM0033-9ZM170)
- Toshiba MG03ACA400
- HGST Ultrastar 7K4000 SAS (HUS724040ALS640)
The above drives do not target the same specific market. For example, the WD Red and Seagate NAS HDD are for 1- 8 bay NAS systems in the tower form factor. The WD Red Pro is meant for rackmount units up to 16 bays, but is not intended to be a replacement for drives such as the WD Re, Seagate Constellation ES.3, Seagate Enterprise Capacity v4 and the Toshiba MG03ACA400 which target enterprise applications requiring durability under heavy workloads. The WD Se and the Seagate Terascale target the capacity-sensitive cold storage / data center market.
Testbed Setup and Testing Methodology
Unlike our previous evaluation of 4 TB drives, we managed to obtain enough samples of the new drives to test them in a proper NAS environment. As usual, we will start off with a feature set comparison of the various drives, followed by a look at the raw performance when connected directly to a SATA 6 Gbps port. In the same PC, we also evaluate the performance of the drive using some aspects of our direct attached storage (DAS) testing methodology. For evaluation in a NAS environment, we configured three drives of each model in a RAID-5 volume and processed selected benchmarks from our standard NAS review methodology. Since our NAS drive testbed supports both SATA and SAS drives, but our DAS testbed doesn't, the HGST SAS drive was not subject to any of the DAS benchmarks. We plan to carry more detailed coverage of the HGST SAS unit in a future SAS-specific roundup.
We used two testbeds in our evaluation, one for benchmarking the raw drive and DAS performance and the other for evaluating performance when placed in a NAS unit.
| AnandTech DAS Testbed Configuration | |
| Motherboard | Asus Z97-PRO Wi-Fi ac ATX |
| CPU | Intel Core i7-4790 |
| Memory |
Corsair Vengeance Pro CMY32GX3M4A2133C11 32 GB (4x 8GB) DDR3-2133 @ 11-11-11-27 |
| OS Drive | Seagate 600 Pro 400 GB |
| Optical Drive | Asus BW-16D1HT 16x Blu-ray Write (w/ M-Disc Support) |
| Add-on Card | Asus Thunderbolt EX II |
| Chassis | Corsair Air 540 |
| PSU | Corsair AX760i 760 W |
| OS | Windows 8.1 Pro |
| Thanks to Asus and Corsair for the build components | |
In the above testbed, the hot swap bays of the Corsair Air 540 have to be singled out for special mention.
They were quite helpful in getting the drives processed in a fast and efficient manner for benchmarking. For NAS evaluation, we used the QNAP TS-EC1279U-SAS-RP. This is very similar to the unit we reviewed last year, except that we have a slightly faster CPU, more RAM and support for both SATA and SAS drives.
The NAS setup itself was subjected to benchmarking using our standard NAS testbed.
| AnandTech NAS Testbed Configuration | |
| Motherboard | Asus Z9PE-D8 WS Dual LGA2011 SSI-EEB |
| CPU | 2 x Intel Xeon E5-2630L |
| Coolers | 2 x Dynatron R17 |
| Memory | G.Skill RipjawsZ F3-12800CL10Q2-64GBZL (8x8GB) CAS 10-10-10-30 |
| OS Drive | OCZ Technology Vertex 4 128GB |
| Secondary Drive | OCZ Technology Vertex 4 128GB |
| Tertiary Drive | OCZ Z-Drive R4 CM88 (1.6TB PCIe SSD) |
| Other Drives | 12 x OCZ Technology Vertex 4 64GB (Offline in the Host OS) |
| Network Cards | 6 x Intel ESA I-340 Quad-GbE Port Network Adapter |
| Chassis | SilverStoneTek Raven RV03 |
| PSU | SilverStoneTek Strider Plus Gold Evolution 850W |
| OS | Windows Server 2008 R2 |
| Network Switch | Netgear ProSafe GSM7352S-200 |
Thank You!
We thank the following companies for helping us out with our NAS testbed:
- Thanks to Intel for the Xeon E5-2630L CPUs and the ESA I-340 quad port network adapters
- Thanks to Asus for the Z9PE-D8 WS dual LGA 2011 workstation motherboard
- Thanks to Dynatron for the R17 coolers
- Thanks to G.Skill for the RipjawsZ 64GB DDR3 DRAM kit
- Thanks to OCZ Technology for the two 128GB Vertex 4 SSDs, twelve 64GB Vertex 4 SSDs and the OCZ Z-Drive R4 CM88
- Thanks to SilverStone for the Raven RV03 chassis and the 850W Strider Gold Evolution PSU
- Thanks to Netgear for the ProSafe GSM7352S-200 L3 48-port Gigabit Switch with 10 GbE capabilities.
Facebook
Twitter
RSS
62 Comments
View All Comments
shodanshok - Sunday, August 10, 2014 - link
It is not a single post. It is a lengthy discussion of 18 different posts. Let me forward you to the first post: http://marc.info/?l=linux-raid&m=1406709331293...When used in single parity scheme, no RAID implementation or file system is immune to UREs that happen during rebuild. What ZFS can do it to catch when a disk suddenly return garbage, which with other filesystem normally result in silent data corruption.
But UREs are NOT silent corruption. They happen when the disk can not read the requested block and give you a "sorry, I can't read that" message.
Regards.
asmian - Sunday, August 10, 2014 - link
>But URE's are NOT silent corruption.They are if you are using WD Red drives, which Ganesh has previously said are using URE masking to play nicer with RAID controllers. They issue dummy data and no error instead of a URE. This, and the serious implications of it especially with single parity RAID (mirror/RAID5), is NOT mentioned in this comparative article, which is shocking.
To reiterate: if a RAID5 array (or a degraded RAID6) has a masked URE, there is no way to know which disk the error came from. And if the controller is NOT continuously checking parity against all reads for speed then the dummy data will be passed through without any error being raised at all. Worse, since you don't know there has been a read error, you will assume your data is OK to backup, so you will likely overwrite good old backups with corrupt data, since space for multiple copies is likely to be at a premium, so any backup mitigation strategy is screwed.
Given the fact that these are 4GB consumer class drives with 1 in 10^14 URE numbers, the chance of a URE when rebuilding is very high, which is why these Red drives are extremely unsafe in RAID implementations that do NOT check parity continuously. I already ran the numbers in a previous post, although they haven't been verified - Ganesh said he was seeking clarification from the manufacturers. Bottom line: caveat emptor if you risk your data to these drives, with or without RAID or a backup strategy.
shodanshok - Sunday, August 10, 2014 - link
Can you provide a reference about URE masking? I carefully read WD Red specs (http://www.wdc.com/wdproducts/library/SpecSheet/EN... and in no place they mention something similar to what you are referring. Are you sure you are not confusing URE with TLER?After all, I find extremely difficult to think that an hard drive will intentionally return bad data instead of a URE.
The only product range where I can _very remotely_ find a similar thing useful is with WD Purple (DVR) series: being often used as simple "video storage" in single disk configuration, masking an URE will not lead to big problems. However, the proper solution here is to implement a configurable SCTERC o TLRE.
Regards.
asmian - Sunday, August 10, 2014 - link
> I find extremely difficult to think that an hard drive will intentionally return bad data instead of a URE.Ganesh wrote to me: "As discussed in earlier WD Red reviews, the drive hopes to tackle the URE issue by silently failing / returning dummy data instead of forcing the rebuild to fail (this is supposed to keep the RAID controller happy)."
shodanshok - Sunday, August 10, 2014 - link
This seems more the functionality of TLER, rather than some form of URE masking. Anyway, if the RED drive really, intentionally return garbage instead of a read error, it should absolutely avoided.Ganesh, can you clarify this point?
asmian - Sunday, August 10, 2014 - link
A quick search back through previous WD Red drive reviews reveals nothing immediately. Ganesh ran a large article on Red firmware differences that covered configurable TLER behaviour, which is about dropping erroring drives out of an array quickly so that the array parity or other redundancy can take over and provide the data that the drive can't immediately retrieve, but nothing like this was mentioned.However, in http://www.anandtech.com/show/6083/wd-introduces-r... the author Jason Inofuentes wrote: "They've also included error correction optimizations to prevent a drive from dropping out of a RAID array while it chases down a piece of corrupt data. The downside is that you might see an artifact on the screen briefly while streaming a movie, the upside is that you won't have playback pause for a few seconds, or for good depending on your configuration, while the drive drops off the RAID to fix the error."
That sounds like what Ganesh has said, although I can't see anything in his articles mentioning it. It may be a complete misunderstanding of the TLER behaviour, though. The problem with the behaviour described above is that it assumes that the data is not important, something that will only manifest as a little unnoticed corruption while watching a video file. But what if it happens while you're copying data to your backup array? What if it's not throwaway data, but critical data and you now have no idea that it's corrupt or unrecoverable on the disk so you NEED that last good backup you took... I don't think ANYONE is (or should be) as casual as that about the intrinsic VALUE of their data - why bother with parity/mirror RAID otherwise? If the statement is correct, it's extremely concerning. If not, it needs correcting urgently.
Zan Lynx - Monday, August 11, 2014 - link
To me that sounds like a short TLER setting. The description says nothing about if the drive returns an error or not. It may very well be the playback software receiving the error but continuing playback.asmian - Monday, August 11, 2014 - link
But a short TLER is designed specifically to allow the array parity/redundancy to kick in immediately and provide the missing data by reconstruction. There wouldn't BE any bad data returned (unless there was no array redundancy). So as described this is NOT anything to do with short TLER. It is about the drive not returning an error when it can't read data successfully (ie. a URE), and issuing dummy data instead. The fundamental issue is that without an error being raised, neither the array hardware/software nor the user can take any action to remedy the data failure, whether that's restoring the bad data from backup or even highlighting the drive to see if this is a pattern indicative of likely failure.There are some comments about it in that article which try to explain the scope (it seems to be limited to some ATA commands), but not in sufficient detail for me or most average users who don't know what ATA commands are sent by specific applications or the file system, and they certainly didn't answer my questions and misgivings.
shodanshok - Monday, August 11, 2014 - link
Hi, it seems more as a short TLER timeout rather than URE masking. Ganesh, can you clarify?ganeshts - Saturday, August 23, 2014 - link
Yes, shodanshok is right ; TLER feature in these NAS drives is a shorter timeout rather than URE masking. Ian's quote of my exchange in a private e-mails was later clarified, but the conversation didn't get updated here:1. When URE happens, the hard drive returns an error code back to the RAID controller (in the case of devices with software RAID, it sends the error back to the CPU). The error code can be used to gauge what exactly happened. A fairly detailed list can be found here: http://en.wikipedia.org/wiki/Key_Code_Qualifier : URE corresponds to a medium error with this key code description: "Medium Error - unrecovered read error"
2. Upon recognition of URE, it is up to the RAID controller to decide what needs to be done. Systems usually mark the sector as bad and try to remap it. It is then populate with data recovered using the other drives in the RAID array. It all depends on the vendor implementation. Since most off-the-shelf NAS vendors use mdadm, I think the behaviour will be similar for all of those.
3. TLER just refers to quicker return of error code back to controller rather than 'hanging' for a long time. The latter behaviour might cause the RAID controller to mark the whole disk as bad when we have URE for only one sector.