[matrix_overload]

They still have valid use cases like backups or unedited video footage. It's just kinda lame that the manufacturers don't market them as "slow backup devices" clearly listing all limitations, and that you have to find it out first time you use it.

[timschmidt]

When I have used them for backups, the 40gb buffer quickly fills and then I'm stuck with speeds slower than my internet connection until the buffer empties, which it will only do if I kill the existing transfer. SSDs can dump 40gb of data very quickly. Annoyingly, since the r/w head has to do it's back-and-forth dance between the buffer area and the SMR areas, this condition even impacts read speeds. Consequently I wouldn't even use them for backups. Nor would I buy them again. I've set them up as Storj drives, which they seem to handle reasonably, and I am thankful to be done with them otherwise.

If you're considering one, I would pay special attention to the buffer size, and ensure that all the transfers you want to do to or from the drive are significantly smaller than the buffer to ensure reasonable performance. That excludes most video too. Storj files are typically just a few megabytes, and typically arrive at a frequency of just one or two per second, which the drive can handle.

[matrix_overload]

I had that problem as well (8TB Seagate). It would write some data, then get completely stuck to the point where Windows would report an I/O error. So I wrote a small tool that writes data in smaller chunks, monitors the write speed and allows throttling it if needed.

Weirdly enough, just using the tool instead of copying files with Explorer somehow stopped the weird hanging from happening, even without having to enable the actual throttling. Probably some bug somewhere along the driver/firmware stack triggered by the write block sizes.

Overall, I wish the drive vendors would expose some API to directly manage the SMR/CMR areas via software, just like the FLASH memory chips do. That would make the job of appending new backups + overwriting the old ones actually manageable with predictable and consistent timing.

[timschmidt]

It also seems like a potential opportunity for hybrid flash hard drives, where the flash could take over the role of the CMR buffer region and reduce the amount of back-and-forth required of the drive's rw head, which should considerably increase performance.

[WithinReason]

This could even happen is SW with separate drives.

[mrkstu]

I assume Apple’s ‘Fusion’ drive tech is still active in their OS for backwards compatibility. It’d be interesting to try it on one of these drives.

[mike_hearn]

It's probably sensitive to exactly how the file is opened. SMR drives need the file to be append only. If Explorer isn't communicating to the OS that it's going to do that properly for whatever reason, the driver would kick the writes back to the random access area which would slow it down.

SMR drives aren't designed for having data shuttled between areas like that. They're meant to be used such that you write in long streams directly to the shingled areas. The slowdowns are clearly due to the abstraction mismatch getting in the way.

[wtallis]

> Overall, I wish the drive vendors would expose some API to directly manage the SMR/CMR areas via software, just like the FLASH memory chips do.

They do, on drive models that are sold to the customers large enough to have the resources to re-write their storage stack to handle zoned block devices. The drives sold at retail will continue to pretend to be ordinary random-access block devices for the sake of backwards compatibility.

[doublepg23]

Are you sure the drive wasn't just DOA?

[matrix_overload]

Got 2 of those. Same behavior, otherwise both work just fine.

[wongarsu]

I was about to comment that this might not be a huge issue in network storage. Throwing a pair of 1TB SSDs as write cache in a Synology is pretty painless. Then I remembered that SMR drives don't like RAID, soo yeah.

Maybe you can make it work in clustered file systems like Ceph if you make sure you have a big enough SSD-based write cache.