News WD Sets the Record Straight: Lists All Drives That Use Slower SMR Tech

[bit_user]

To a certain extent, wasn't that the point of the Black drives also (long warranty, suitable for - but not targeted at - RAID usage, better overall product with the best internals)?

Yeah, probably right. In 2010, I got 5x 1 TB Blacks and used them in a software RAID (even though they lacked TLER). After 10 years (but only about 1.5 years of spinning), they all still work perfectly and zero errors.

That's a slam-dunk product, right there. Too bad my 2017 4 TB Gold drives (which I got to replace them) were not as good. One failed, almost straight away. The 2019 4 TB Gold, that I got as a replacement, is much better.

Anyway, I agree with your analysis. I sort of doubt they'll sneak SMR into the Purple line, though*. I wonder if those aren't the best "budget" option, for NAS users who want to steer clear of SMR.

* Video surveillance HDDs have to handle 24/7 writing (as well as bursty reading, without significant delays). Therefore, even though most writes are fairly sequential, there's not necessarily an opportunity for the drive to go back and coalesce non-sequential writes. Also, they can't afford to massively sacrifice read performance at the expense of writes.

 

[vincero]

Yeah, probably right. In 2010, I got 5x 1 TB Blacks and used them in a software RAID (even though they lacked TLER). After 10 years (but only about 1.5 years of spinning), they all still work perfectly and zero errors.

That's a slam-dunk product, right there. Too bad my 2017 4 TB Gold drives (which I got to replace them) were not as good. One failed, almost straight away. The 2019 4 TB Gold, that I got as a replacement, is much better.

Anyway, I agree with your analysis. I sort of doubt they'll sneak SMR into the Purple line, though*. I wonder if those aren't the best "budget" option, for NAS users who want to steer clear of SMR.

* Video surveillance HDDs have to handle 24/7 writing (as well as bursty reading, without significant delays). Therefore, even though most writes are fairly sequential, there's not necessarily an opportunity for the drive to go back and coalesce non-sequential writes. Also, they can't afford to massively sacrifice read performance at the expense of writes.

I dunno... As they are constantly doing sequential IO that is the one thing SMR doesn't have an issue with even if it has to read from another area at the same time it can go back and resume writing an SMR zone without having to clear the block and start again (although that depends on how smart the management is).

The alternative is to chase a slightly lower density level and have SMR zones that are much smaller but more manageable and imperceptible in terms of performance hit.

If they were say 32MB instead of 256MB, they'd be easier to cache, quicker to write and quicker to read and rewrite - the process taking a fraction of a second instead of more than a second. It would also mean the block sizes are small that the drive may still be able to commit data in the event of a power fail scenario if it had just started a rewrite of an entire block. They may loose out on their ~25% density increase to a lower level but I'm sure it would still be there and the user experience wouldn't suck as hard.
It would also mean coalescing non-sequential data could be done more easily - perhaps even stored in RAM cache instead of special disk area - until enough of a block of data has been streamed to then write it out (which in vid surveillance / NVR / DVR scenario would be a short time).

 

[bit_user]

I dunno... As they are constantly doing sequential IO that is the one thing SMR doesn't have an issue with even if it has to read from another area at the same time it can go back and resume writing an SMR zone without having to clear the block and start again (although that depends on how smart the management is).

It doesn't matter how smart the management is, because surveillance software is recording from multiple cameras, simultaneously, usually each to its own file. So, that ends up being quite a lot of read amplification, if you want to sequentialize those writes. And you can only do one band at a time, meaning you have to do like N reads of N times the number of blocks per band, where N is the number of cameras being recorded. It's really pretty bad.

You could do it host-managed, but then you shift costs to demand for a huge amount of RAM on the host. So, either way, it would only scale up to DVRs with a low camera count. Not a good solution.

The other thing about surveillance is that the disks are always nearly full. So, that forces coalescing to be a fairly continual process, in spite of whether the user is going back and trying to play some recorded video, at the time.

The alternative is to chase a slightly lower density level and have SMR zones that are much smaller but more manageable and imperceptible in terms of performance hit.

As you shrink the bands, the benefits of SMR rapidly evaporates. Pretty soon, you might as well just use CMR and avoid the performance hit.

It would also mean the block sizes are small

Blocks are 4 kB. It was a big deal, when the industry switched from 512 B, so I don't expect that to change.

It would also mean coalescing non-sequential data could be done more easily - perhaps even stored in RAM cache instead of special disk area

That entirely depends on how many streams are being written. If it's 32, even having 32 MB bands (which I'm still not convinced is viable), that would mean you need 1 GB of RAM on the drive, which could more than kills the cost savings of going SMR.

And 32 cameras is still a fairly small number. I've seen surveillance recorders that scale all the way up to 256.

 

[vincero]

It doesn't matter how smart the management is, because surveillance software is recording from multiple cameras, simultaneously, usually each to its own file. So, that ends up being quite a lot of read amplification, if you want to sequentialize those writes. And you can only do one band at a time, meaning you have to do like N reads of N times the number of blocks per band, where N is the number of cameras being recorded. It's really pretty bad.

You could do it host-managed, but then you shift costs to demand for a huge amount of RAM on the host. So, either way, it would only scale up to DVRs with a low camera count. Not a good solution.

The other thing about surveillance is that the disks are always nearly full. So, that forces coalescing to be a fairly continual process, in spite of whether the user is going back and trying to play some recorded video, at the time.


As you shrink the bands, the benefits of SMR rapidly evaporates. Pretty soon, you might as well just use CMR and avoid the performance hit.


Blocks are 4 kB. It was a big deal, when the industry switched from 512 B, so I don't expect that to change.


That entirely depends on how many streams are being written. If it's 32, even having 32 MB bands (which I'm still not convinced is viable), that would mean you need 1 GB of RAM on the drive, which could more than kills the cost savings of going SMR.

And 32 cameras is still a fairly small number. I've seen surveillance recorders that scale all the way up to 256.

It may be streaming seperate files to the drive but the drive management will still write the data interleaved together from what I've seen with current SMR drives (DVR and their drives do the same when capturing several streams at least when the drive is clean). The problem comes when parts of these recorded files (or individual files for video segments depending on the NVRs design) then get overwritten and the drive will need to cope with that - which it will struggle with, but hey I'm sure their best minds are on it - I guess they could benefit from TRIM support so it would then know that blocks within a band are junk and if the drive always maintains spare band space not exposed to the user it can just write to a clear band and move different physical areas to the necessary LBAs (something they are already doing) and coalesce whatever it needs to and mark the old band as clear.

For block size I meant the SMR band/block size, not physical sector size (mostly irrelevant now). Shrinking the band sizes obviously reduces the benefit of density (not sure there are any other than density - there's certainly more negatives), but would definitely improve band rewrite / coallescing delays so even if that cost say 5% of the SMR density gain that would be a better drive from a consumer aspect.

To be honest, I wouldnt expect anyone with more than say an 8 channel system at most to be using such a drive - you'll get to the point where (a) the video may be more valuable so redundancy may be needed, (b) the IO will require a higher performance device, not necessarily a DVR/NVR focused one, and (c) depending on retention of data you may have tiered storage of the video.

 

[DeComposer]

I look forward to the public naming and subsequent sacking of the WD Marketing VP who approved the deceptive practice at the root of this fiasco.

 

[bit_user]

It may be streaming seperate files to the drive but the drive management will still write the data interleaved together from what I've seen with current SMR drives (DVR and their drives do the same when capturing several streams at least when the drive is clean). The problem comes when parts of these recorded files (or individual files for video segments depending on the NVRs design) then get overwritten and the drive will need to cope with that

Yes, that's the point I was trying to make.

which it will struggle with, but hey I'm sure their best minds are on it

If the solution doesn't suit the problem, then it doesn't matter how badly you want it to work. Wishful thinking is not a plan.

they could benefit from TRIM support so it would then know that blocks within a band are junk

Yes, one of the articles or maybe a forum post said you can infer whether a WD drive is SMR, based on whether it supports TRIM. In this case, I think that won't help very much.

if the drive always maintains spare band space not exposed to the user it can just write to a clear band and move different physical areas to the necessary LBAs (something they are already doing) and coalesce whatever it needs to and mark the old band as clear.

They can't maintain enough spare bands not to be continually coalescing the data. And, like I said, that's going to suffer serious read amplification, depending on how many streams are being written.

even if that cost say 5% of the SMR density gain that would be a better drive from a consumer aspect.

You're just throwing numbers around, at this point. Do you even know how many MB per track, in a modern CMR HDD? It seems like you'd need to know how many tracks per band, in order to have any clue how much you're giving up by shrinking them.

To be honest, I wouldnt expect anyone with more than say an 8 channel system at most to be using such a drive - you'll get to the point where (a) the video may be more valuable so redundancy may be needed,

Why do you assume they're not in a RAID-1, -5, or -6?

(b) the IO will require a higher performance device, not necessarily a DVR/NVR focused one, and (c) depending on retention of data you may have tiered storage of the video.

Well, each camera is probably recording a few megabits/s. The media transfer rate of a HDD is a couple hundred MB/s. So, the native throughput is there. I've seen security systems which record 64 cameras on a 6-disk RAID-5.

Anyway, they did not yet list any Purple drives as SMR. I will be very interested, if they do.

 

[bit_user]

I look forward to the public naming and subsequent sacking of the WD Marketing VP who approved the deceptive practice at the root of this fiasco.

I doubt it'll happen. The decision was probably made at a fairly high level and, for all we know, WD was just reacting to Seagate or Toshiba.

I did give you a "Like", because it'd be nice to see a further acknowledgement of what a bad move this was.

 

[gggplaya]

To a certain extent, wasn't that the point of the Black drives also (long warranty, suitable for - but not targeted at - RAID usage, better overall product with the best internals)?
WD progressively hobbled the range from having TLER, probably to ensure sales of their raptor/gold drives as the ultimate product, to the point you'd almost only purchase the black for the extra warranty and slightly better numbers over the blue range (especially now in the age of the SSD it's almost just a choice of "you can have one of our hard drives OR a slightly better one, but still nowhere near as fast as an SSD, for a bit more but with a longer warranty also").
Now some have SMR in their 'performance' product... Again I'm not saying SMR is slow for transfers but random write is the enemy.
Hell, their first SSHD was in the WD Black family - that's the kind of new features people want to see, not SMR.

Can't help but think this is a by product of dropping the green line into the blue so effectively no longer having a 'budget' version of the red and hence ending up with the Red Pro as the 'real Red' drives and the current red as just the budget low energy always on drive.
Looking at it like this makes it more logical but this is where consolidation of branding works against you. WD are having the latest version of a silent spec change causing a PR moment like Kingston when they changed NAND spec mid product life cycle.

My impression back in the day, before SSD's became main stream, was that WD Black were their performance series. They were 7200rpm and designed for the fastest performance. I never got the impression they were suitable for raid arrays where you want less vibration and cooler operation. That said, I would never expect SMR in a performance drive, even if it is a laptop drive.

 

[gggplaya]

If anyone is interested: I ran into the same issue, 7 WD Red drives (WD60EFAX) with sub-par performance. I have contacted WD about it and am documenting the entire ordeal as the story unfolds. You can read about it here: http://riii.me/wd60efax

Thanks for the read on your blog, but to be fair the EFRX is actually a more expensive drive, they were $225 for 6TB and on sale you could get them for about $199. At the end of their life, late last year the lowest I saw was about $180. The WD red PRO 6tb are now $205 which takes their place.

Switching to SMR enabled WD to cut costs and lower their price to $155 because I'm assuming they dropped a platter. They attempted to compensate for the loss in performance by increasing cache size, but I'd much rather take the CMR drive. My raid 5 array with 3 EFRX 6TB drives gets consistent large file transfers over 150MB/s all day long. Write speeds are about 80-120MB/s.

 

[stoatwblr]

Many NAS implementations seem to ignore the ever increasing likelihood of SMR drives being in a pool.

How exactly are you supposed to DETECT a SMR drive when the industry-agreed mechanisms to query for SMR is deliberately not implemented in these drives?

There are a number of discussions about how to deal with SMR drives which SAY they are SMR drives. THESE DRIVES HAVE BEEN HIDING THEIR INNARDS

 

[jalek]

Really must wonder about WD for any server use anymore. We've had trouble with externals for a long time after too many shadow copies, but WD doesn't claim they're compatible for Windows Server OS's anyway. We've had "Archive" drives that would take themselves offline repeatedly apparently for this, they take a long time to resilver.
The large HGST drives have been using this a while, but that was not only disclosed but published in press releases with those drives. We haven't deployed any for any corporate systems because of that.

The worst thing is going to a client to explain why the array you just rebuilt with a replacement drive needs that drive replaced two weeks later. They generally don't care about the reasons, it's just bad. We did that with SSD's that had failure issues, but at least those weren't intentional.

 

[marcolopespt]

Someone said this is part of a RACE for BIGGER capacities. It can be... BUT, before that happens, WD is probably using the most demanding customers / environments to TEST SMR tech so they can DEPLOY them in the bigger capacity DRIVES: 8, 10, 12, 14TB and beyond (do not currently exist). I say this because, WD has the same "infected SMR drives" using the well known PMR tech! https://documents.westerndigital.co...et-western-digital-wd-red-hdd-2879-800002.pdf

Why is that? Why keep SMR and PMR drives with the SAME capacity in the same line and HIDING this info from customers? So they can target "specific" markets with the SMR drives? It seems like a marketing TEST!!! How BIG is it?

Note that currently, the MAX capacity drive using SMR is the 6TB WD60EFAX, with 3 platters / 6 heads... So... is that it?? Is WD USING RAID / more demanding users as "guinea pigs" to test SMR and then move on and use SMR on +14TB drives (that currently use HELIUM inside to bypass the theoretical limitation of 6 platters / 12 heads)??? Is that the next step? And after that, plague all the other lines (like the BLUE one, that already has 2 drives with SMR). I'm thinking YES!! And this is VERY BAD NEWS. I don't want a mechanical disk that overlaps tracks and has to write adjacent tracks just to write a specific track!!!

Customers MUST be informed of this new tech, even those using EXTERNAL SINGLE DRIVES ENCLOSURES!!! I have many WD external drives, and i DON'T WANT any drive with SMR!!! Period!

Gladly, i checked my WD ELEMENTS drives, and NONE of the internal drives is PLAGUED by SMR! (BTW, if you ask WD how to know the DRIVE MODEL inside an external WD enclosure, they will tell you it's impossible!!! WTF is that??? WD technicians don't have a way to query the drive and ask for the model number?? Well, i got new for you: crystaldiskinfo CAN!!! How about that? Stupid WD support... )

So, if anyone needs to know WHAT INTERNAL DRIVE MODEL they have in their WD EXTERNAL ENCLOSURES, install https://crystalmark.info/en/software/crystaldiskinfo and COPY PAST the info to the clipboard! (EDIT -> COPY or CTRL-C). Paste it to a text editor, and voila!!!
(1) WDC WD20EARX-00PASB0 : 2000,3 GB [1/0/0, sa1] - wd
(2) WDC WD40EFRX-68N32N0 : 4000,7 GB [2/0/0, sa1] - wd
Compare this with the "INFECTED" SMR drive list, and you're good to go!

P.S. I will NEVER buy another EXTERNAL WD drive again without the warranty to check the internal drive MODEL first!!!! That's for sure!

 

[marcolopespt]

I risked for a NEW external WD drive, and i got a WD40EDAZ inside an external ELEMENTS enclosure!!!

I feel ripped off!

I just hate that consumers don't have a clue about the drive inside external enclosures, and need to open the package to check the hard drive info. Now it's gonna be a HASSLE to return it! I just REFUSE to buy SMR drives! Period! Have contacted WD support to ask for "permission" to return this to the reseller.

I wish there was a way to buy external hard drives without falling into this russian roulette...

I thought the only possibility to get a 4TB SMR drive would be the WD40EFAX!!! https://www.tomshardware.com/news/wd-lists-all-drives-slower-smr-techNOLOGY

I guess not!!! There are a LOT of new models! https://rml527.blogspot.com/2010/10/hdd-platter-database-western-digital-35_9883.html

 

[plausible_deniability]

Dec 5, 2020,

Just saw on WD's website, (2-day sale) WD Black 2.5" SATA lll WD5000LPSX (500 GB) and the 1TB model as now available in SMR along with the 250, 320 and 500GB available in CMR . The "Come Clean List" from April didn't have the 2.5" 500GB Black in SMR so either they've been making the 500 in SMR all along or just decided to insult the Black line yet again.
Thankfully no 3.5" Blacks ever used SMR in 640GB or 1TB ... that I can find.

 

[Justin Goldberg]

Thank you, next....