Western Digital Blog

It's probably worth changing the link to the official blog post: https://blog.westerndigital.com/wd-red-nas-drives/ Anyway, this is all I wanted from them. "Here are what technologies each drive uses, and we'll be more transparent in the future." Now I can be confident in what I'm getting when I buy a Western Digital drive. Good for them!

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.

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

Hmm, so what about these modern high density hard drives which store track parameters for their servos in on-board flash (aka OptiNAND)? Do we get "spinning rust" which might loose the information where exactly it stored the data? https://blog.westerndigital.com/optinand-explained/

> they design their own SSD controller silicon in-house And they've been leaning into RISC-V[1] due to this. [1]: https://blog.westerndigital.com/risc-v-swerv-core-open-source/

The one you want at home right now is CMR, or Conventional Magnetic Recording. S is Shingled, H is Heat Assisted, while the article mentions P for Perpendicular which became conventional after nobody has room for L or Longitudinal. Explainer: https://www.linuxadictos.com/en/diferencias-entre-smr-cmr-pmr.html WD NAS apology tour: https://blog.westerndigital.com/wd-red-nas-drives/ Seagate's CMR/SMR list: https://www.seagate.com/products/cmr-smr-list/

Yes. However Western Digital is predicting latency of the same order as Optane DIMMs in this 2016 blog: https://blog.westerndigital.com/storage-class-memory-3d-nand-lessons/ CXL Optane wasn't going to happen because of the necessity for drivers in either block or direct access mode. Couldn't plug and play. CXL itself is a good reduction in buss latency and there's been virtually nothing other words the occasional battery backed NAND DIMM on any memory buss, so SCL on CXL isn't going to be poor.

(circa:2013) >Moore’s Law Dead by 2022, Expert Says< : <https://www.eetimes.com/moores-law-dead-by-2022-expert-says/> (circa:2020) >We’re not prepared for the end of Moore’s Law< : https://www.technologyreview.com/2020/02/24/905789/were-not-prepared-f… Edit: >What Happens After Moore's Law?< : https://blog.westerndigital.com/what-happens-after-moores-law/

It's unclear if there's a global limitation, but my reading is that the limit of 64k operations is per IORING_OBJECT. There's nothing that says you can't have multiple submission queues; for example, the NVMe spec allows 64k commands per queue on up to 64k queues. (On the other hand, there's nothing that says that multiple submission queues is a good match for any given application either, but in the storage world it often is). In any case, given how popular NVMe is, I assume IORING_OBJECT would support this model. https://blog.westerndigital.com/nvme-queues-explained/

See e.g. https://blog.westerndigital.com/risc-v-swerv-core-open-source/

WD has published a list of SMR drives : https://blog.westerndigital.com/wp-content/uploads/2020/04/2020_04_22_…

https://blog.westerndigital.com/wd-red-nas-drives/ - it has since been edited though.

For those unwilling to disable their Adblocker, here is the official WD blog post with PDF containing make and model numbers: https://blog.westerndigital.com/wd-red-nas-drives/

For anyone wondering "why", this linked article in the source gives some background, https://blog.westerndigital.com/storage-architectures-zettabyte-age/ So instead of SMR harddrives and SSDs doing extra work to hide their deficiencies, they're pushing this up into the filesystem. In return you get slightly more storage and slightly faster IO. Perhaps not useful on a desktop, but very useful when dealing with thousands of storage devices in a data centre. In terms of how it would be exposed to users, this feels very well fitted with object storage. Unlike file-based storage, each object can only be read or replaced. So any partial write relies on the program to read the whole object, then write the updated object.

How I can distinguish news discussing a processor core design (seemingly, usually, marketed as a "core") from that discussing hardware that I can actually buy (a processor "chip")? I would have thought that 1. https://blog.westerndigital.com/risc-v-swerv-core-open-source/ 2. https://greenwaves-technologies.com/ai_processor_gap8/ and 3. https://syntacore.com/page/products/processor-ip/scr1 would be pieces of hardware that I can buy. Instead, they seem to be designs for hardware which conform to the RISC-V ISA, which could then be fabbed by a semiconductor manufacturer or flashed onto an FPGA. What marketing/technical terms distinguish the designs of these systems from their implementations? "Core", "processor", "MCU"/"microcontroller", for example? Are any/all of these uniquely constrained to describing either a design (on paper) or that design's physical implementation in hardware?

You are exactly right. WD explains the same in https://blog.westerndigital.com/rise-helium-drives/ : «Without air, the heads will crash into the disk»

HGST won't be with us for much longer either due to the recent WD rebranding [1][2]. As part of the unification of our new Western Digital brand, the Ultrastar DC HC320 is being introduced under the Western Digital Data Center (DC) segment branding. All new commercial and enterprise products going forward will carry this new Western Digital branding as we transition away from the HGST brand. Western Digital has gone through a significant transformation with the integration of multiple companies. Moving to the Western Digital brand for all of our commercial and enterprise products is the first step in unifying the brands in our portfolio. [1] https://blog.westerndigital.com/western-digital-sets-new-high-lower-ca… [2] https://www.hgst.com/products/hard-drives/ultrastar-dc-hc320

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… [1]: https://blog.westerndigital.com/risc-v-swerv-core-open-source/

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 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.

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

> RISC is China / Eastern Imo this is a really strange characterization of RISC. I've never seen this before. I think you try to paint a misleading picture in bad faith, please consider this: - https://riscv.org/blog/how-nvidia-shipped-one-billion-risc-v-cores-in-… - https://tenstorrent.com/en/ip/risc-v-cpu - https://blog.westerndigital.com/risc-v-swerv-core-open-source/ - https://www.sifive.com - ... - https://riscv.org/about/ -> "RISC-V International Association in Switzerland"