6 TB NAS Drives: WD Red, Seagate Enterprise Capacity and HGST Ultrastar He6 Face-Off
by Ganesh T S on July 21, 2014 11:00 AM ESTPerformance - Raw Drives
Prior to evaluating the performance of the drives in a NAS environment, we wanted to check up on the best-case performance of the drives by connecting them directly to a SATA 6 Gbps port. Using HD Tune Pro 5.50, we ran a number of tests on the raw drives. The following screenshots present the results for the various drives in an easy-to-compare manner.
Sequential Reads
The Seagate Enterprise Capacity drive, as expected, leads the benchmark numbers with an average transfer rate of around 171 MBps. The HGST unit (142 MBps) performs better than the WD Red (126 MBps) in terms of raw data transfer rates, thanks to the higher rotational speed. The burst rate of the Seagate drive is also higher. In effect, the higher amount of cache memory on the Seagate drive helps it to perform well in this test.
Sequential Writes
A similar scenario plays out in the sequential write benchmarks. The Seagate drive leads the pack with an average transfer rate of 168 MBps followed by the HGST one at 139 MBps. The WD Red's 123 MBps is the slowest of the lot, but these results are foregone conclusions due to the lower rotational speeds in the Red.
Random Reads
In the random read benchmarks, the HGST and Seagate drives perform fairly similar to each other in terms of IOPS as well as average access time.
Random Writes
The differences between the enterprise-class drives and the consumer / SOHO NAS drives is even more pronounced in the random write benchmark numbers. However, the most interesting aspect here is that the HGST Ultrastar He6 wins out on the IOPS for 512B transfers due to its sector size. Otherwise, the familiar scenario that we observed in the previous subsections play out here too.
Miscellaneous Reads
HD Tune Pro also includes a suite of miscellaneous tests such as random seeks and sequential accesses in different segments of the hard disk platters. The numbers above show the HGST and Seagate drives matched much more evenly. The cache effects are also visible in the final graph.
Miscellaneous Writes
Similar to the previous sub-section, we find that the Seagate and HGST drives quite evenly matched in most of the tests. The HGST drive does exhibit some weird behaviour with the burst rate test and the Seagate one with the 8 MB random seek tests, while the Red is consistent across all of them without being exceptional.
We now have an idea of the standalone performance of the three drives being considered today. In the next section, we will take a look at the performance of these drives when subject to access from a single client - as a DAS as well as a NAS drive.
Facebook
Twitter
RSS
83 Comments
View All Comments
brettinator - Friday, March 18, 2016 - link
I realize this is years old, but I did indeed use raw i/o on a 10TB fried RAID 6 volume to recover copious amounts of source code.andychow - Monday, November 24, 2014 - link
@extide, you've just shown that you don't understand how it works. You're NEVER going to have checksum errors if your data is being corrupted by your RAM. That's why you need ECC RAM, so errors don't happen "up there".You might have tons of corrupted files, you just don't know it. 4 GB of RAM has a 96% percent chance of having a bit error in three days without ECC RAM.
alpha754293 - Monday, July 21, 2014 - link
Yeah....while the official docs say you "need" ECC, the truth is - you really don't. It's nice, and it'll help to mitigate like bit-flip errors and stuff like that, but I mean...by that point, you're already passing PBs of data through the array/zpool before it's even noticable. And part of that has to do with the fact that it does block-by-block checksumming, which means that given the nature of how people run their systems, it'll probably reduce your ERRs even further, but you might be talking like a third of what's already an INCREDIBLY small percentage.A system will NEVER complain if you have ECC RAM (and have ECC enabled, because my servers have ECC RAM, but I've always disabled ECC in the BIOS), but it isn't going to NOT startup if you have ECC RAM, but with ECC disabled.
And so far, I haven't seen ANY discernable evidence that suggests that ECC is an absolute must when running ZFS, and you can SAY that I am wrong, but you will also need to back that statement up with evidence/data.
AlmaFather - Monday, July 28, 2014 - link
Some information:http://forums.freenas.org/index.php?threads/ecc-vs...
Samus - Monday, July 21, 2014 - link
The problem with power saving "green" style drives is the APM is too aggressive. Even Seagate, who doesn't actively manufacture a "green" drive at a hardware level, uses firmware that sets aggressive APM values in many low end and external versions of their drives, including the Barracuda XT.This is a completely unacceptable practice because the drives are effectively self-destructing. Most consumer drives are rated at 250,000 load/unload cycles and I've racked up 90,000 cycles in a matter of MONTHS on drives with heavy IO (seeding torrents, SQL databases, exchange servers, etc)
HDPARM is a tool that you can send SMART commands to a drive and disable APM (by setting the value to 255) overriding the firmware value. At least until the next power cycle...
name99 - Tuesday, July 22, 2014 - link
I don't know if this is the ONLY problem.My most recent (USB3 Seagate 5GB) drive consistently exhibited a strange failure mode where it frequently seemed to disconnect from my Mac. Acting on a hunch I disabled the OSX Energy Saver "Put hard disks to sleep when possible" setting, and the problem went away. (And energy usage hasn't gone up because the Seagate drive puts itself to sleep anyway.)
Now you're welcome to read this as "Apple sux, obviously they screwed up" if you like. I'd disagree with that interpretation given that I've connected dozens of different disks from different vendors to different macs and have never seen this before. What I think is happening is Seagate is not handling a race condition well --- something like "Seagate starts to power down, half-way through it gets a command from OSX to power down, and it mishandles this command and puts itself into some sort of comatose mode that requires power cycling".
I appreciate that disk firmware is hard to write, and that power management is tough. Even so, it's hard not to get angry at what seems like pretty obvious incompetence in the code coupled to an obviously not very demanding test regime.
jay401 - Tuesday, July 22, 2014 - link
> Completely unsurprised here, I've had nothing but bad luck with any of those "intelligent power saving" drives that like to park their heads if you aren't constantly hammering them with I/O.I fixed that the day i bought mine with the wdidle utility. No more excessive head parking, no excessive wear. I've had 3 2TB Greens and 2 3TB Greens with no issues so far (thankfully). Currently running a pair of 4TB Reds, but have not seen any excessive head parking showing up in the SMART data with those.
chekk - Monday, July 21, 2014 - link
Yes, I just test all new drives thoroughly for a month or so before trusting them. My anecdotal evidence across about 50 drives is that they are either DOA, fail in the first month or last for years. But hey, YMMV.icrf - Monday, July 21, 2014 - link
My anecdotal experience is about the same, but I'd extend the early death window a few more months. I don't know that I've gone through 50 drives, but I've definitely seen a couple dozen, and that's the pattern. One year warranty is a bit short for comfort, but I don't know that I care much about 5 years over 3.Guspaz - Tuesday, July 22, 2014 - link
I've had a bunch of 2TB greens in a ZFS server (15 of them) for years and none of them have failed. I expected them to fail, and I designed the setup to tolerate two to four of them failing without data loss, but... nothing.