> I would of thought the Purples would have been one of the least bad places for SMR in consumer drives, since it's pretty much just all sequential load. I've

> I would of thought the Purples would have been one of the least bad places for SMR in consumer drives, since it's pretty much just all sequential load. I've tried out a couple Seagate SMR drives for NVR use. They weren't advertised as SMR but I figured it out from the observed performance and the "rated workload" on the spec sheet. It's okay if you stay within the rated workload, but that's pretty limiting. This is given in the spec sheet in terabytes per year; if you divide by 4 you have approximately Mbps. One of my drives (ST8000DM004-2CX188) is rated for 55 TB/year, or 14 Mbps. It seems fine with 2 cameras that each have a <= 6 Mbps main stream and <= 1 Mbsp sub stream. But if you want to record a bunch of streams to one drive (perfectly reasonable with CMR), these can't do it. When device-manager SMR is used with a standard filesystem (I'm using ext4) and non-SMR-aware software/write patterns (my software just writes new files with ~1-minute segments of H.264 and deletes old ones), the write amplification gets bad and the drive can't keep up. The software just gets stuck waiting for writes/syncs to go through. And it's really confusing to observe on the host because all the mapping and stuff is hidden from you. You just see on "iostat" that the "%util" is much higher what you'd calculate based on seek + throughput for the data you're transferring. I imagine with host-managed SMR and SMR-aware software, this could be much better. Most NVRs mostly just record in a ring buffer—for a given stream, they almost always overwrite the oldest data. You could bypass the whole CMR cache area and not read/rewrite any adjacent areas if you do it well, and then the write amplification would go away.