If they increased the size to 4TB say, to make it easier to import data to it, it might be worth it. But if it takes several days to write 32GB of data to it, it's not really gonna be worth it to most people.
I've wondered why WD/Seagate don't invest in a consumer solution where drives are literally just plug and play together and give you raid without the hassle of a raid controller or software. Eg. An 8TB drive connected to an 8TB drive is a mirrored raid. SMR drives would serve as "cold storage". Once written to, would never be rewritten again.
if you want that I think they do have in box solutions with two or more drives and a while back sold their own NAS drive system. Not sure what they have today but there are plenty of free or free enough solutions out there these days.
0: https://hackaday.com/2015/06/08/hard-drive-rootkit-is-fright...
I feel like 10gb superspeed hardware is more than a fast enough connection. The hardware is relatively cheap to build, it's just the software.
I'm not saying you need a super high speed processor or memory either, since the SMR drive itself can serve can serve as (slow) memory for the CPU. The trick is trying to figure out mostly how to replicate blocks across the raid, and then mapping the files to raid blocks.
They are wonderful for write once/read many storage of large files. Due the the sheer number of drives the write speed isn’t a major concern as it can saturate the 20gbps Ethernet bond to the machine.
Reads are the multi-GB/sec range though, so long as they are sequential.
They would not be my first choice, but for specific uses like backups and media storage they are a good value.
Linear writing and reading of 30Gb files is a great use case for it.
Edit: Actually I think we now have an equivalent of the DMCA so breaking the encryption on the Blu-ray would be infringing that. Oh well.
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.
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.
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.
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.
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.
I got a Lenovo laptop for the parents a long time ago that had a hybrid hard drive; I think maybe 8 or 16GB builtin SSD. Man that thing was just absolute trash, so slow; ghastly long boot times or time to launch a browser.
Ideally a SMR drive has a SMR capable file-system, where it can write data into linear logs & them try to batch rewrite the metadata. Even the pathologically terrible random writes can be somewhat coped with via accommodating fs.