The Western Digital corporate blog covers storage products, NAS drives, SMR, zoned storage, NVMe and RISC-V.
HN links it as an official source: commenters welcomed its WD Red disclosure of drive technologies and cite its RISC-V and OptiNAND posts.
This is pretty spot on, so there's not much to add but a some somewhat disorganized thoughts:
Object storage and block storage are similar -- the difference is usually how they're accessed but isn't necessarily (ex. s3 via FUSE projects can be thought of as block storage). Some examples of the blurring of this line:
- https://github.com/minio/minfs
- https://github.com/archiecobbs/s3backer
- https://github.com/yandex-cloud/geesefs
Hard drives are in the business of "block storage" -- you offer them a block of bytes (if you wanted to you could tell the hard drive exactly where to write the bytes, rather than using the file-based interfaces that are common), they put it on some sort of media (rotational, solid state, whatever), end of story.
Applications often only need a higher abstraction on storage -- not bits and bytes, but instead files or "objects". Most applications don't need the ability to access one or more bytes (in... a block) of an area on disk, they often only want access to entire files (roughly a 1:1 mapping with objects, with how 99% of the people use object storage).
Getting back to the question, block storage is usually interacted with via a completely different set of technologies -- iSCSI[0][1], NVMeOF[2], etc. The idea here is that you're talking to a hard drive on the other end, and it make sense to speak the language (or a language) of hard drives. Object storage is normally interacted with via HTTP. The expected/tolerated latencies using these…
I really wouldn't mind buying special purpose hardware. In fact, I think I prefer it.
The whole story here is that modern SSD controllers tend to embed a bunch of very fast very expensive data-processing cores to quickly do a ton of fancy mapping. We don't hear it quite as clearly these days, but for example for a while higher end Samsung SSD controllers were announced as penta-core ARM Cortex-R[1] systems, and I think those Cortex-Rs are what most folks do. (It was groundbreaking news that WD released an open source "swerv" RISC-V core which they'd experimented with using instead, https://blog.westerndigital.com/risc-v-swerv-core-open-source/ .)
Ideally, the fantasy is, we can build much cheaper & faster controllers that do far less. Zoned Namespace drives should ideally have enterprise grade, fast, dual-port access, but in many ways, I feel like they should ideally be far cheaper than DRAM-less drives. They should leave even more up to the host. They should be incredibly dumb & simple drives. They should be lower power, by far. They should eskew DRAM. Drop all the legacy baggage & expose what you are, un-intermediated, so we can be fast & use it well. Which you, the drive, with all purpose tasks, could never do.
It's not worth it, to me, to make a drive that still keeps the ancillary old baggage of convention. If you want to make a good ZNS drive, make a good ZNS drive.
[1] https://en.wikipedia.org/wiki/ARM_Cortex-R
I believe the April 20th (bottom) section of this blog post is the post in question:
https://blog.westerndigital.com/wd-red-nas-drives/
TLDR: They suggest different RED drives should be considered for different workloads. While that may have been their intention all along, that was not communicated well at in marketing or retail, where the drive colors (red, blue, purple, etc) used to be the appropriate method for selecting the right drive for your workload/purpose.
The way they have worded it, the blog is not wrong, but they left out an important fact: consumers didn't have the necessary info to make the decision they're suggesting people should have made.
Even if you read the data sheets that were available at the time, one would expect the listed transfer rate was a limit that the drive was capable of, not the rate that if exceeded would cause the device to perform very poorly. Worse, there would be no way to know that was the case because the fact that they were SMR technology was previously unreleased and the drives themselves actively hid that information from the host computer (since they were "device managed" SMR).
The data sheets still aren't clear on how the performance is impacted with workload, but at least they're clear about the technology they use now.
So rather than getting stuck in potential future tarpit of AWS or GCS or Azure, or probably a dozen other companies, we should voluntarily put ourselves into the IP tarpit developed by ARM? How exactly is that a win?
Over the last two decades ARM has developed a stranglehold on the non-x86 world, and they have already considered abusing this position to increase their profit margin[0]. As a chipmaker you're essentially stuck with ARM, as getting rid of them means you not only need to redesign your chips, but you also need to completely overhaul the entire downstream ecosystem.
With RISC-V there's at least the possibility of switching to a different IP vendor. That might not practically happen with bleeding-edge SoCs, but that kind of flexibility is quite important for the far larger dime-a-dozen MCU market. It's exactly why companies like Western Digital are investing in RISC-V and even developing open-source implementations[1]. Compute is essentially a commodity already, so why not tear down the walled gardens and force it to be one?
[0]: https://www.techpowerup.com/300385/arm-could-change-licensing-model-to-charge-oems-directly
[1]: https://blog.westerndigital.com/risc-v-swerv-core-open-source/
I think direct manipulation never went away, but the abstractions that were provided for general use were too useful to pass up for most workloads.
Some kinds of storage like cloud-scale object storage use custom HDD firmwares and custom on-disk formats instead of filesystems (±2005-era tech), we also have much newer solutions that do direct work on disks like HMR (not to be confused with HAMR or HAMMER2) where the host manages the recording of data on the disk. There are some generally available systems for that, but we also have articles like this: https://blog.westerndigital.com/host-managed-smr-dropbox/ (Which mostly focuses on SMR but this works on CMR too).
As for the record size in the DB vs. Disk attributes, that's probably not used like that anymore, but I do know that filesystem chunks/extents/blocks are calculated and grouped to profit from optimal LBA access. If you run ZFS and have it auto-detect or manually set the ashift size to make it match the actual on-disk sector size. This was especially relevant when 512e and 4Kn (and the various manufactures 'real' and 'soft' implementations) weren't reliable indicators of the best sector access size strategies.
Maybe this is mentioned somewhere in the article, I haven't read the whole thing, but its important to elaborate: SMR is only in-place on WD Red drives between 2TB-6TB [1]. Everything smaller and larger than that uses CMR, and SMR isn't used on any other 3.5" drives beyond their budget "blue" drives. This is now cross-elaborated on their Amazon (US) istings; their 2TB-6TB Red drives are in a totally different product listing [2] which says "SMR" in the title (versus their CMR drives [3])
I don't like that they hid it. If they want to keep SMR around for their 2-6TB Red variants, I think they should reclassify those drives with another "color" and not certify them for server applications (WD Pink?)
[1] https://blog.westerndigital.com/wd-red-nas-drives/
[2] https://www.amazon.com/Red-4TB-Internal-Hard-Drive/dp/B07MYL7KVK
[3] https://www.amazon.com/Red-12TB-Internal-Hard-Drive/dp/B07RQ99XJH