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.
On the other hand, the Black with SMR is just shocking, considering that's their "performance" line.
> 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.
Surveillance is sequential write load with hard real-time requirements, though. The unpredictable delays inherent to SMR could present serious problems.
No, the write load is nearly constant. With a fixed-size buffer in the drive, you're pretty close to optimal use case for SMR. There's no source of variance except for where the SMR mechanism adds it, and that's analogous to a garbage collector sweep. Size and frequency depend on dirty rate.
Even on a freshly formatted drive, you'd want your write rate to stay below what the SMR rewrite process can handle. If the drive fills up and it needs to delete something to make room before writing new video, its ability to keep up with the incoming video data is going to be reduced.
Lots of recording systems won't record unless the camera sees motion. Or they record at a much lower frame rate until motion is detected & then go into high speed mode to capture fine details. So that helps, and the CMR buffer also helps. But if the recording fills up the CMR buffer, you're back to incoming data potentially arriving faster than SMR can rewrite.
Time to drop back to 1080 HD cameras from 4k cameras maybe. Or reduce the number of cameras.
edit This is comparing a SMR to a similar CMR drive. Obviously, any drive can run into trouble if you exceed its write capabilities. But a SMR drive's write rate is going to be lower than a CMR drive, once it's buffer area is full. And especially if you're doing random writes.
The write load will be nearly constant but it won’t be sequential. The host device is going to have to update file system data structures periodically as it is writing the video stream; those structures will be at various different places on the drive. So the write load will look like 99% sequential, 1% random. That small amount of random writes in a non-contiguous stream is enough to cause SMR-related rewrite stuttering, especially since with DMSMR the host has no idea how logical blocks presented by the drive map to SMR regions.
Surveillance data is recorded on top of the old one, which means all writes are rewrites and that is the worst case scenario for a SMR drive.
A host-managed drive with carefully aligned zones may avoid this issue in this scenario, but I don't know how far a drive-managed SMR drive can mitigate it.
These drives don't even support TRIM. So I think as far as they're concerned, once the drive is filled, every write is a rewrite no matter the exact workload. I think the concept of drop-in, device-managed SMR, but let's try to hide that is nowhere near as good as what's possible with host management in terms of the write load it can sustain.
It looks like it was just the 1T black. Still... would have never suspected they would SMR in the black line. Truth be told.. it was the last think I expected in the red.
Why you would buy a spinning rust drive that's only 1TB if you care about performance is a big mystery. 1TB is available in not overly expensive SSDs now. That is a drive with almost no use case. A quick search suggests it's about $100 cheaper than the SSD, but unless your budget is absolutely inflexible that extra $100 would be incredibly well spent on upgrading the drive. More so than almost any other place on the machine.
I'd never consider buying one new - but I do have some 2-4TB blacks that I had for Steam. Funny how terribly unloved the old 15k 300G velociraptor sitting next to me - replaced by something costing about eight quality beers.
Had I a stack of them, I would have considered the black line safe for home NAS. Apparently not, now that I know.
You can probably tune how much of a hit SMR is by changing the size of the CMR region. The more CMR area you have, the more you can sustain bursts of writes without needing to reduce performance for recording recent writes into their respective final resting places. It's more or less the same logic of hybrid drives, with the difference reading from CMR is not faster than from SMR, so you can deallocate already SMR'ed information immediately after a successful write.
When you rebuild a drive in a RAID array the size of the CMR region doesn't matter though, your array is either going to explode due to the latency spikes that come or take weeks to rebuild.
Isn't it possible to query the drive and, if it is SMR, just send the data to the disk in the order it expects so that it can resilver the drive one SMR region at a time?
This seems more like a misunderstanding between the drive and the OS in that the drive doesn't tell the OS it'll need a break between write batches and an OS that tries to write to the disk in a way that's not compatible with the device technology.
The same more or less applies to SSDs - the drive can't write a disk block, but only a memory block at once.
This aggressive segmenting of drives into colors/use cases just serves to confuse me. I wish they'd just clearly state on boxes exactly what feature set the drives have - i.e. "vibration sensor, sustained write speed, SMR/CMR" etc
On the other hand, the Black with SMR is just shocking, considering that's their "performance" line.