Enlarge /. EFAX Red from Western Digital – an SMR hard drive – is competing against a Seagate Ironwolf in today's tests.
Western Digital has received a storm of bad press – and even complaints – about its attempt to inject SMR hard drive technology into its "red" line of NAS hard drives. To get a better grip on the situation, Ars bought a Western Digital 4 TB Red EFAX SMR drive and tested it himself.
Enlarge /. Although Western Digital's 4TB SMR hard drive performed adequately in Servethehome's light tests, performance was miserable when used to replace a hard drive in a dilapidated four-drive RAIDz1 vdev.
Recently, the well-known tech enthusiast website Servethehome tested one of the SMR-based 4 TB Red hard drives with ZFS and found that it is painfully missing. The hard drive has performed adequately, if not overwhelmingly, in general performance tests. When Servethehome replaced a hard drive in a dilapidated RAIDz1 vdev, it took more than nine days to complete the process – when all competing NAS drives performed the same task in about 16 hours.
This rightly raised questions about what Western Digital was thinking when it tried to use SMR technology in NAS drives, let alone try to bring them to market. Had Western Digital even tested the hard drives? As valuable as Servethehome's ZFS tests were, they ignored the most common use case of this drive class – NAS devices for end users and small businesses like DS1819 + from Synology or ReadyNAS RN628X00 from Netgear. All use Linux kernel RAID (mdraid) to manage their arrays.
Rebuild a 75% full RAID6 array with eight hard drives
After purchasing a WD 4 TB Red EFAX drive like the one tested by Servethehome, we used our existing test rig with eight Seagate Ironwolf drives in the Ars Storage Hot Rod to create a RAID6 array. Our eight Ironwolf hard drives are 12 tons each, so we split them up to 3500 GB each. This made the array so small that our new WD Red hard drive could "fit" as a replacement if an Ironwolf failed.
When creating the RAID6 array, we used the -b none argument to prevent trying to do a bitmap scan for faster rebuilds when using a hard drive that was previously in the array. And we formatted it with the ext4 file system with the arguments -E lazy_itable_init = 0, lazy_journal_init = 0 so background processes don't contaminate our tests with drive activity that normal users don't normally struggle with.
After formatting the new 19 TB array with eight hard drives, we saved 14 TB of data in fourteen subdirectories, each containing 1,024 1 GB files filled with pseudorandom data. This brought the array to just over 75 percent. At this point, we removed an Ironwolf hard drive from the array, ran a wipefs -a / dev / sdl1 to remove the existing RAID headers, and then reinserted it into the now degraded array. That was our basis.
After the iron grinder was successfully installed in the array, we failed it again – and this time we completely removed it from the system and replaced it with our 4 TB red SMR guinea pig. First, we added the entire 4 TB red to the degraded array as a replacement for the missing, partitioned iron wolf. After the rebuild was complete, we failed again, deleted the RAID header, and added it again to rebuild it a second time.
This gave us our two test cases – a brand new red SMR hard drive that is being converted into an array and a used red SMR hard drive with lots of data that has already been converted into an array. We thought it was important to test both methods, because in the real world NAS hard drives are often used in any case. It also seemed likely that an SMR disk full of data will perform worse than a brand new one that doesn't need to read, change, or write because it deals with zones that are already in use.
Enlarge /. The SMR EFAX was easily converted into our conventional RAID6 array – even if 75% of its capacity was already occupied.
We weren't surprised that the SMR hard drive performed adequately in the first test – aside from consumer anger, Western Digital seemed unlikely to have sent these hard drives out the door without any testing. We were more surprised that when it was used it worked the same way it did when it was new – the drive's firmware was able to mix data so well that it didn't take an extra minute to restore it from a "used" state if new.
Simple 1MiB random write test
The SMR WD Red again offers adequate performance – it does not win speed tests, but does not fall flat on the face.
Checking the latency of each return is a little more informative. In terms of average latency, the EFAX Red is okay, if not convincing.
If we go to maximum latency, we can begin to see the real problems of the WD Red – we see up to 1.3 full seconds to save 1 MB of data in the worst case.
The firmware of the WD Red was clearly up to the challenge of performing a conventional RAID rebuild that was equivalent to an enormous, very large sequential block write test. Next, it should be checked whether the EFAX can handle a heavy version of the typical everyday use case of a consumer NAS, ie store large files.
At first glance, the WD Red passes the pattern again. In terms of throughput, the Red is only 16.7 percent slower than its non-SMR Ironwolf competition. Even re-testing if the firmware has trouble handling zones that are already full will not change the picture significantly.
If we go a little further and look at fio's latency numbers, things look noticeably worse. The EFAX Red is 68.8 percent slower to return from surgery than the Ironwolf on average – but again, this is the area "not winning the race", not "you will be sued for fraud". Only when we look at the maximum latency from the 1MB random write test will we find out how bad things can get if you push the red in unplanned directions. The worst case rate of return is a whopping 1.3 seconds, which is well over ten times worse than the slowest rate of return of the iron wolf of 108 milliseconds.
We can extrapolate from this result of the peak latency that the throughput of the red firmware, if it starts to falter heavily, can drop below 1 MB / s for a while – and this correlates with the constantly changing throughput numbers that we are performing who have seen throughput tests. It also shows us that for a desktop user who wants things to happen when they click buttons and drag things around, the red occasionally offers a really frustrating experience during a very, very simple workload, even for a traditional drive.