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.
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.
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.
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.
timschmidt|1 year ago
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|1 year ago
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.
wongarsu|1 year ago
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.