Does the revelation that they use SMR somehow change their reliability or performance ?
I fail to see how it makes the drives any less useful only because it is revealed that it is SMR and not PMR.
It is models from 2TB to 6TB, meaning pretty much all NAS drives purchased in the past decade.
I don't know about yours, by my drives perform just as well as they did yesterday.
>Shingled media recording (SMR) disk drives take advantage of disk write tracks being wider than read tracks to partially overlap write tracks and so enable more tracks to be written to a disk platter. This means more data can be stored on a shingled disk than an ordinary drive.
>However, SMR drives are not intended for random write IO use cases because the write performance is much slower than with a non-SMR drive. Therefore they are not recommended for NAS use cases featuring significant random write workloads.
[...]
>We brought all these points to Western Digital’s attention and a spokesperson told us:
[...]
>"In device-managed SMR HDDs, the drive does its internal data management during idle times. In a typical small business/home NAS environment, workloads tend to be bursty in nature, leaving sufficient idle time for garbage collection and other maintenance operations."
That seems like a pretty notable difference to me. You probably want to know that ahead of buying the drive.
> Therefore they are not recommended for NAS use cases featuring significant random write workloads.
Emphasis mine: a NAS featuring "significant random write"s, is not the usual NAS, and might not actually be best described as a NAS at all.
In WD's terms, they'd tell you that if you've got e.g. your /var partition mounted over SMB to your NAS, then your NAS is receiving a Desktop workload, and so you should use their Desktop drives in it, not NAS drives. (Consider: the drives backing Amazon EBS—which receive Server workloads—are certainly not "archival media" disks, despite being nominally "network-attached storage" disks.)
The use-case for WD Red (NAS) drives is online archival media storage. Like S3 without the high availability. In other words, the thing most people buy a NAS for: backups and home Plex hosting.
This is why, I assume, WD don't literally call these drives "WD NAS", but instead just call them "WD Red." Just because you put them in a NAS, doesn't mean they'll function well there. You have to be using them for an idiomatic NAS workload. (Which also means that WD Red drives fare just fine in a desktop or server, too, if you're using them there purely for an idiomatic NAS workload.)
>In WD's terms, they'd tell you that if you've got e.g. your /var partition mounted over SMB to your NAS, then your NAS is receiving a Desktop workload, and so you should use their Desktop drives in it, not NAS drives.
That's still obfuscation bordering on scam IMO, if the drives have technical limitations they should be spelled out, not hidden behind broad terms like "NAS drive", especially when they're branded the same way as older drives that didn't have these limitations.
Also, you'll have to explain to me how having these drives perform correctly while rebuilding a RAID array is not a "usual NAS" scenario. Because reading TFA it seems like getting these drives in a NAS to begin with is a challenge on its own.
Yeah, that seems pretty scummy to be. I was under the impression that "NAS" drives were objectively better than "Desktop" drives.
The clerk at the computer shop tried to upsell me on the NAS drives, chortled when I said "the "I" in RAID stands for "Inexpensive" and told me that I would regret my purchase.
It seems to me that my cheapness inadvertently paid off?
That's all well and good, but, given a sufficiently large array, it's a matter of when, not if, you'll need to recover from a failed disk, rebuilding a RAID array is precisely the expected sort of workload for a NAS — and a workload that reports indicate these drives fail at.
Except they don't, because apparently SMR is slower to write than conventional recording, so the device buffers writes to conventional tracks, then uses idle-time to re-write the buffered data to SMR tracks.
About 80:20 by units sold, I would say; leaning slightly more toward the latter by volume of drives sold, by the fact that businesses buy the larger NASes that take more drives in them, because they're actually somewhat serious about RAID recovery.
But you've got to further subdivide the use-case: a file server for a business is still not necessarily doing "random writes." You can create and replace as many small files on a filesystem as you like, and in a modern filesystem, you'll only be doing large batched writes to the disks themselves. It's only when you're writing within existing files—i.e. writing to a database of some kind—that you see a high number of random-write IOPS hitting the disk.
Mind you, there are a lot of things that turn out to have databases in them. A Chrome profile has a couple of SQLite databases in it. An iTunes library contains a database. Etc. These are the things that—if you stuck them on your NAS, and then pointed the relevant program at them from your PC—would constitute the NAS performing a "Desktop" workload. And, obviously, if you run Postgres on your NAS—or on a system that mounts a NAS disk over iSCSI—then that disk is doing a "Server" workload.
But the average business's use of e.g. shared Excel worksheets, does not "heavy random writes" make. Document/productivity software is almost always of the "on save, do a streaming overwrite of the whole file on the remote end" variety—which, again, is not a random-write workload, since the ftruncate(2) at the beginning allows the filesystem to grab a new free extent for the overwrite to write into.
Most software that knows that it can be used in a shared-remote-disk setting is built to accommodate that shared-remote-disk setting by attempting to minimize random writes (since this kind of workload has always been slow on the kind of storage used in NASes and SANs, especially when your filesystem or software RAID does checksumming.) These days, it's only the software that absolutely can't help it—that needs random writes to be performant at all—that still does them. And it's pretty obvious, to anyone using such software, that they're not using "NAS friendly" software. Mostly because it's so dang slow!
>Does the revelation that they use SMR somehow change their reliability or performance ?
Yes, they do not perform anywhere like PMR on writing.
It's so bad they simply should _never_ be used on a RAID or Zpool, where they have such pathological behaviour on resilvers that can easily become the trigger for data loss.
I would never buy one of these voluntarily, as they'd cause me headaches.
So, definitely, I need to know whether what I am buying is SMR or PMR. And wd's behaviour is unacceptable.
Yes, they perform worse, but there is a bigger issue. They lie. The drives report themselves as being PMR when they should be reporting themselves as SMR. They actually lie about their technology type in the firmware.
The article implies that's only recent revisions of the 2-6 TB products that use SMR, noting issues with "the latest iteration of WD REDs (WDx0EFAX replacing WDx0EFRX)"
I fail to see how it makes the drives any less useful only because it is revealed that it is SMR and not PMR.
It is models from 2TB to 6TB, meaning pretty much all NAS drives purchased in the past decade. I don't know about yours, by my drives perform just as well as they did yesterday.