Since I posted my review article on the Seagate 8Tb Archive HDD, which uses SMR technology, I have had several readers complain that I was getting much better results in benchmarks than they were, and their numbers were much worse by comparison. That in turn, resulted in me writing this article, to take a little more time to explain why this might be the case.
An issue with slow or inconsistent storage performance, especially with writes, can occur due to the write cache being disabled. This seems to be the default setting for many motherboards intended for server environments – say the HP Microserver series of computers.
I discovered this by accident, many years back, when I owned my first HP Microserver N36L and I was benchmarking a WD Black 2Tb drive. Instead of getting >100MB/s writes, I was seeing only 50MB/s, and it was unable to saturate a GbE link. I had no such issues with other computers, and the drive itself was benching fine in other machines.
Of course, a little investigation revealed that you can toggle the write caching setting to “on” in the BIOS, or you can make changes via Device Manager in Windows. By navigating to Disk Drives, and selecting your hard disk, then the policies tab, you can alter the write caching settings directly.
Generally, it’s a good idea to have the first box ticked, and the second box unticked, as in the screen-shot above. As it turns out, most consumer motherboard BIOSes default to write-caching on, so this setting may already be correct for your computer (as it was on almost all of my own builds).
The reason write caching is avoided by some users is that it increases potential for data loss when the system is unexpectedly powered down. It also increases the amount of time that data which is due to be written spends in volatile DRAM.
However, write caching does improve performance because writes are first collected in memory and then collectively written to the drive. This can improve performance by collecting multiple writes together into a queued transaction which for SMR drives, can improve the persistent cache utilization, and it reduces CPU loading (generally) because the CPU doesn’t have to be involved so often with handling each and every write individually.
However, write caching is not new, and was already around back in the smartdrv MS-DOS/Windows 3.1 days, and was a recommended optimization back then. I would say, if you run without write caching, you really are hampering your performance mostly unnecessarily. Without write caching, I’ve had SSDs benchmark with ~50MB/s write speed as well, possibly due to CPU limitations, and I am not unique.
Of course, if you tick the bottom box, you can get additional speed benefits, but with additional levels of risk.
Performance Comparison – PMR vs SMR, Cache On vs Cache Off
For the naysayers who might not believe me, I’ve spent a whole week benchmarking drives to show what the differences are. In this case, lets start with a traditional PMR drive
PMR Write Cache On
PMR Write Cache Off
When the write cache is enabled, the drive averages 137.2Mb/s write speed, but with the cache off, the speed drops to 116.3Mb/s. This is not that big of a penalty, which is probably why having write cache off with this PMR drive is not as noticeable. However, this is hardly the worst example, as I’ve had other PMR drives and SSD drives react even worse.
SMR Write Cache On
SMR Write Cache Off
Note that the beginning on the SMR Write Cache On graph was actually write-cache off, and then I realized and toggled the setting. The SMR drive is very sensitive to the write cache setting, and the performance becomes slower than even a USB 2.0 drive once it’s been hammered continually with writes (as I did). It falls from 148MB/s down to 24.9MB/s average write speed, and again, the CPU utilization increases.
This probably explains why there have been so many negative reactions to the SMR drive – the users are likely to be running with write caching off, as I suspected, and the drive is very sensitive to this condition with very slow throughput rates as a result.
If you want to use the SMR drive sensibly, I don’t think there’s much of a choice. You want write caching on.
Of course, another contributor to slow hard drive speeds can be a sub-optimal link rate. You can check this with a reasonable amount of accuracy using CrystalDiskInfo, where it will show you the currently used rate, and the drive’s maximum supported rate.
In this case, it is connected at SATA/300 rates, when the drive is capable of SATA/600 rates. This is generally okay, as most hard drives do not eclipse about 220MB/s (where SATA/300 starts running out of steam), but if you saw SATA/150, then you are likely to see limitations in the speed on the outer tracks.
Of course, you will see even worse results if your drive us connected via USB 2.0, where most controllers struggle to eclipse 30MB/s. USB 3.0 connections can vary significantly in speed, but 100MB/s is a given, and up to 450MB/s could be achieved if a UASP-supporting chipset is connected to a UASP-supporting USB 3.0 host (i.e. running Windows 8 or newer, as UASP is not available in Windows 7 and realistically means about 200MB/s top speed due to lack of command queueing in USB Bulk-only Transport mode).
Of course, slow speeds can be a sign of poor drive health, and checking that with SMART diagnostics like CrystalDiskInfo is a good idea. For example, I salvaged this drive out of an ex-corporate system, did a full random write to clear the pending sectors. This drive now shows up as Caution, but it hasn’t tripped any of the SMART impending failure thresholds, so it still claims to be healthy to the BIOS. You get no warnings booting from this drive.
But knowing just how bad it is – 338 reallocated sectors in 301 reallocation events, the drive certainly isn’t a good candidate for reliability. More shockingly is the resulting throughput –
I haven’t finished the benchmark because it is literally that slow, but the drive is really having issues. The 30MB/s limit is due to the use of a USB 2.0 bridge chip, but the drive fails to even saturate that. The throughput is really inconsistent, and drops down to unbelievably low levels despite not throwing a read error.
It seems that some hard drives do try very hard at reading and writing data, even though it takes longer and it’s unable to meet the expected throughput levels, so an unhealthy drive will be slow.
Secondly, the act of reallocations also decreases the speed of a drive, as sectors become stored “out of order”, meaning the head will have to seek to a new location in a spare band to retrieve the spare sector. That normally causes short transient dips in a throughput graph, but nothing of this magnitude.
File System Utilization
Finally, another cause of slowness, although this one is more an application-level perceived slowness, has to do with your file system and how it records files. Hard drives typically perform poorly when data is scattered around the drive in fragments, and this causes unnecessary seeking which creates noise, consumes energy, and wastes time.
This is why, at least for Windows, it makes sense to de-fragment a hard drive to reassemble (as best as possible) files into contiguous sectors to speed up reading, and improve the effectiveness of the read-ahead cache on the hard drive itself.
Of course, other operating systems (especially Linux) have fragmentation-resistant file systems that reduce this issue to an insignificant level unless you deliberately try to provoke fragmentation.
Whatever you do, it is not advisable to defragment SSD drives, as it is not as necessary to do so as their seek times are negligible, and it will consume program-erase cycles which are limited in flash memory. That being said, an occasional defragment may have cache-benefits and improve the chance of file-signature data recovery when your filesystem is completely destroyed, as it relies on files being stored in continuous blocks. This is not a consideration for most users though.
Hard drives can be slow for a number of reasons, some of which I have touched on above. That being said, it seems that the SMR drive is more sensitive to write caching being turned off, and this explains the disparity between my results and those of others who may not have write caching turned on. It might surprise you that most of your machines might already have write caching turned on, so by installing the same drive on a different motherboard, you could get different test results because of this difference. The risk of data loss is generally very low, and acceptable for consumers. The alternative is, higher CPU utilization and very slow performance from SMR drives.