Hacker News Reader

Comment by tjoff | Hacker News Reader

I have such a hard time to understand how the risk vs. reward ratio for pulling this stunt made any sense.

SMR does not have a great reputation, to put it in drives specifically targeted for NASes and enthusiasts is a very bold move.

View on HN

>I have such a hard time to understand how the risk vs. reward ratio for pulling this stunt made any sense.

Classical economics likes to think of firms as rational entities working to maximize profit over the long term. In my experience that makes much of what companies do inexplicable. Instead I view firms as large groups of individuals all acting in their own self interest, this seems more complex but really all you have to know is what the incentive structure is to understand the choices a company makes. Similarly I've found you can also do this in reverse. It is a virtual certainty that from a compensation perspective moving to SMR was better for the individuals who made that choice.

Fortunately, economic theory is more broad than classic economics.

Managerial and behaviour theories here:

https://en.wikipedia.org/wiki/Theory_of_the_firm

Linked to from the Economics article under the Theory section:

https://en.wikipedia.org/wiki/Economics

The theory your suggesting here has been known since at least the late 50s.

You might also be aware of, or find interesting anyway, the principal–agent problem:

https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

Edit: typo

I don't think this reply should be downvoted. It might be slightly spicy, but it does reflect that economics in the 20th century made enormous strides in understanding the observable behaviour of actual firms and markets.

Transaction costs, agent problems, information economics, institutional economics, mechanism design and so on are powerful insights into the world around us. I've learned more about how software grows and spreads from economists than from software engineers.

It's a useful bit of information, but it's insulting the comment it replies to without actually disagreeing at all. There's a reason the initial comment said "classical" economics! I can see why it earned some downvotes.

Not everything we write here has to be disagreement or a counterpoint.

I can see how it might have come across as brusque, I certainly didn’t intend any insult.

I was not insulted. The links added further reading and more context.

Excellent, this is good :)

> SMR does not have a great reputation

SMR is fine if you know what SMR is and what you're doing. It might even be fine given a sufficiently advanced translation layer (which apparently doesn't exist yet). The problem isn't SMR, it's selling a product which uses SMR and hiding that fact from the consumer, and I can't forgive WD for that.

> It might even be fine given a sufficiently advanced translation layer (which apparently doesn't exist yet).

Apparently f2fs does well with it?

Not terribly surprising, f2fs and similar filesystems are log-based systems. Rather than overwrite the old data they almost always try to write to the next new area. This ends up working really well for flash technology because writing to existing areas is expensive. You have to read in a 1-4MB area depending on the block size, make your changes to that, erase that area entirely, and then write the changed version. [Those sizes might be a little off but it's what I remember]. Some of that may be hidden by the disk's controller but it has to happen on every write to an area with existing data. SMR is similar in this respect because you have to read, change, and write large blocks together because of the way the tech works. So I'd expect anything that's directly optimized for low level flash memory to work similarly ok performance wise for it.

The real problem comes when you can't work like that, in particular this happens when you're low on free space or if you're in a situation where relocating data isn't possible or known that it needs to happen. RAID setups are typically the worst case for this, since they'll effectively treat the entire disk as used and can't relocate data on it. ZFS is a bit more complicated with this but effectively ends up the same.

There have been some experiment with modified XFS using SMR drives natively:

https://www.snia.org/sites/default/files/SDC15_presentations...

You put the journal and metadata on the continuous part and data on the shingled part, making sure you only ever add to what was written previously in a shingled segment by using copy-on-write. And sporadically you reclaim a segment.

This should be much more efficient than a block layer translation layer that knows nothing about the filesystem.

Well, no. SMR is not fine. What this debacle showed, very clearly, is that SMR collapses under some workloads. RAID rebuilds failed. Some took a week, but some just failed.

Will my hard drive's workload ever resemble that of a NAS RAID rebuild? Or will there be another workload which breaks SMR drives?

Key here is that workloads change, and weird issues like this one lead to compounding failures in emergencies. A system might have an SMR-friendly workload during it's normal operations, but during a cyberattack? When debugging an outage? It's impossible to predict what I'll be doing when the unexpected comes up.

Above all else, I want my storage medium to be reliable and to not have issues like this. It's clear SMR drives aren't there yet.

Yes, if there was a sufficiently advanced translation layer, or the right abstractions to the OS, SMR might be fine. But the present state-of-the-art of SMR technology is very obviously unsuitable for any application where you care about your data.

I'll mention early SSDs were in a similar state many years ago, with wear leveling algorithms. But there was a difference in the level of transparency there.

Given the price premium on these drives in the first place I don't even get why they'd do this? Stick the SMR drives in the EasyStore line or whatever, which is regularly half the $/gb of the bare RED drives. That'd probably also discourage some shucking.

In every company, no matter how obscene the margins they're making on a given product, there is someone arguing that those margins could be even larger if they just cut a few corners.

Eventually someone listens to that person, and decades of painstakingly built-up brand value gets thrown out the window in order to bring home six nickels tomorrow instead of five.

As mentioned in the Manfred Berger talk, the tech is supposed to, in theory, get you a 25-50% cost effectiveness advantage. Obviously the market prices don't reflect that, but that explains why they'd do this.

Reality seems to be more like 10% on a capacity basis. On a performance basis, of course, it's extremely negative.

Magnetic disks are generally valued on capacity, but at least as I heard the talk, he was talking about it growing to a 50% difference as they pushed the limits.

I get that the reds are more performance oriented, but capacity is still a key factor (if not, you just go SSD and be done with it).

I get that 50% has been the sort of marketing aim for "why bother support SMR at all," but until they actually get there, it's just marketing. Reality is ~10%.

Magnetic disks are valued on capacity only because people considered CMR HDDs a performance floor. When they realize how bad SMR is, I think performance becomes a factor.

If you're talking about GB per volume, SSDs beat HDDs of all stripes there: the biggest HDDs are 16 TB in a 3.5" form factor, while the biggest SSDs are 100 TB in the same form factor. 10 or 50% improvement in HDDs wouldn't begin to bridge that gap.

SMR should be understood to be sort of a fast Tape, rather than slow CMR HDD.

> SMR should be understood to be sort of a fast Tape, rather than slow CMR HDD.

I wouldn't go that far. If I can assume that the firmware won't cause a lot of problems all by itself, I think in my desktop I'd slightly prefer a 7200RPM SMR drive to an equal-price 5400RPM CMR drive.

And no matter what kind of hard drive(s) you're using, take a $20 SSD and use half of it as a cache with writeback enabled.

> SMR should be understood to be sort of a fast Tape, rather than slow CMR HDD.

In fairness, more like an array of tape drives. ;-)

I get what you're saying about how it hasn't panned out in reality, but the question was why did they even try SMR, and I expect that was motivated by the misguided potential of the win.

But perhaps the manufacturing costs do reflect it? In which case the profits would be much, much higher than normal drives.

They do. Corresponding 2-6TB Blue drives are also SMR and that are shipped inside external drives. Only Reds got the attention because of ZFS issues.

I suspect Blue and Red drive have a lot of common in manufacturing they switched all drives in same capacity together.

Red is getting attention not just because of ZFS, but because Reds are targeted and marketed for workloads that don't work well with SMR.

It was well known before that Red are trash compared to Red Pro which IIRC are rebranded HGST DeskStar NAS.

SMR is not as bad for desktop-style workloads as you might think. If you have enough storage for cache and metadata, you can get great performance because all of your writes are sequentialized.

If you had 32GB of Optane and 4 TB of SMR properly tuned that would be one heck of a desktop drive, but (1) you have to really eliminate all the bottlenecks and (2) who needs a desktop drive large enough that SMR is worth it?

The problem is that once the buffers are full the drive effectively stops accepting commands while it rewrites a SMR region.

When that happens depending on what your doing, the drive might just get kicked from an array, or your whole system might freeze if some critical page needs to be read back in and it can't get sufficient priority and a command slot.

I guess the vast number of people won't ever write more than a buffers full of data, or the drive will never get fragmented sufficiently that even small write operations amplify into entire drive rewrites.....

Smarter firmware would detect the case you are discussing, and re-designate a part of the SMR drive to be regular(non-SMR space).

For that to work, you need the host OS to be able to see that the drive has just "shrunk". Obviously, you still have data on it while it's shrinking, so the reality is the OS needs to give the drive a list of sectors which can be "shrunk away".

One simple approach would be for a daemon to create a massive file filled with "MAGICBYTESMAGICBYTESMAGICBYTES...". As that data is 'written' to the drive, the drive sees that it's the magic bytes, and rather than storing the data, simply marks those sectors as no longer needed. As soon as enough sectors in a row have that designation, reformat them as non-smr, and use as regular (non-smr) disk space.

Then, a few hours or days later, the drive can rewrite the data back to be SMR, then tell the daemon, which can remove the magic bytes and delete the files, and your free disk space increases again.

The failure mode of this is that your "6TB" SMR disk ends up with a 3TB file filled with MAGICBYTES, and 3TB of your data. But for the same money, you'd only get to store 3TB of data on a non-SMR drive anyway...

That is sorta the reverse of what the QLC drives are doing, in that they treat the cells as a lower density cell which is faster/etc until the drive gets to the point where it needs to use QLC to get the stated capacity. That works though because individual page writes are at least a couple orders of magnitude faster on a QLC than the SMR region on a disk.

Shrinking the disk is _MUCH_ harder, there are various enterprise storage arrays which are basically thin provisioned dedupe/etc arrays, and they overwhelmingly just lie about the capacity and throw up big warnings if the physical capacity is being approached. Then depending on which filesystem your running in linux, if they abort writes, there is a good chance the filesystem is damaged (some handle it better than others, and its getting better).

> One simple approach would be for a daemon to create a massive file filled with "MAGICBYTESMAGICBYTESMAGICBYTES...". As that data is 'written' to the drive, the drive sees that it's the magic bytes, and rather than storing the data, simply marks those sectors as no longer needed. As soon as enough sectors in a row have that designation, reformat them as non-smr, and use as regular (non-smr) disk space.

You could nearly get there today with drive firmware only, and no special OS support, using TRIM. The OS can already tell the firmware what space it doesn't need, so the firmware could do what you suggest with this information. The only catch (and difference from your proposal) is that there's no way for the firmware to tell the OS that the space is currently not available, so if the OS puts pressure on that space the firmware would still need to block writes while it SMR-izes and frees the space it previously borrowed.

In other words, drive firmware could use space freed by TRIM for SMR-ization caching today, with no OS modifications.

Ars Technica did some detailed testing of these drives a couple weeks ago. See "We put Western Digital’s dreaded SMR Red drive to the test" [1]. They found that they won't work for ZFS but are actually OK in most NASes.

Here is their conclusion:

-------- begin quote

We want to be very clear: we agree with Seagate's Greg Belloni, who stated on the company's behalf that they "do not recommend SMR for NAS applications." At absolute best, SMR disks underperform significantly in comparison to CMR disks; at their worst, they can fall flat on their face so badly that they may be mistakenly detected as failed hardware.

With that said, we can see why Western Digital believed, after what we assume was a considerable amount of laboratory testing, that their disks would be "OK" for typical NAS usage. Although obviously slower than their Ironwolf competitors, they performed adequately both for conventional RAID rebuilds and for typical day-to-day NAS file-sharing workloads.

We were genuinely impressed with how well the firmware adapted itself to most workloads—this is a clear example of RFC 1925 2.(3) in action, but the thrust does appear sufficient to the purpose. Unfortunately, it would appear that Western Digital did not test ZFS, which a substantial minority of their customer base depends upon.

These tests may not be great news for either the American or Canadian class-action lawsuits currently underway against Western Digital, but they aren't the end of the line for those lawsuits, either. Even in the best case, the SMR models of WD Red underperform their earlier, non-SMR counterparts substantially—and consumers were not given clear notice of the downgrade.

If the same firmware was being used to make substantially larger drives available to consumers than would otherwise be possible, and the limitations of those drives were adequately explained, we would probably be gushing over its utility and function. Unfortunately, Western Digital has so far only chosen to use it to cut manufacturing costs on small disks, without even passing the savings along to the consumer.

-------- end quote

That last paragraph may be key. It sounds like if these drives had been marketed a little different and priced a little different they could have been a good deal for many NAS users.

I wonder what the chances are that they were originally intended for just that, and something got mixed up or miscommunication between design and release?

[1] https://arstechnica.com/gadgets/2020/06/western-digitals-smr...

I did a reshape, in phase 1 from 4-drive RAID5 to 5-drive RAID6 and then, in phase 2, from 5-drive RAID6 to 8-drive RAID6. Everything with Synology NAS, with typical Synology setup (mdraid, btrfs on top).

The new 4 drives were the infamous 6TB EFAX. The phase 1 took 12 days, the phase 2 took 3 days. So my personal experience is radically different than Ars Technica's.

Hi tzs - Jim who wrote that Ars article (and confirmed our original finding) actually commented on the link above, noted how he did not test these in a Synology type solution. His is an important data point, but it, like ours, is only one.

After we published our numbers, we found that it was not just ZFS, but other NAS vendors as well. People were sending us their experiences on non-ZFS systems. For example, Synology users were having issues and Synology took them off their compatible list. QNAP for its part is working on ZFS as we discuss in there as well.

Reply on news.ycombinator.com