Edit: The SMR drives aren't terrible if you know what you're getting and plan accordingly. My machine hosting an SMR mirror for backups is slower than any of my other arrays, but that's fine, since it's usually network-limited. I went SMR because it was cheaper per-TB than the other options at that size, and it's Good Enough. If you can choose SMR and PMR at the same or similar price point, though, obviously go PMR, it's much faster for writes, and very slightly faster for reads.
The "know what you're getting and plan accordingly" part can be tricky though. Trust me, you don't want to go there.
Last summer, my new RAID-6 array nearly died because of Seagate DM004 drives. Two drives got kicked from the array one night, and the rest of the DM004 drives were struggling. Problem was, Linux md RAID + ext4 can pile up enough random write requests during high I/O load to overwhelm the drive's internal SMR management, resulting in periods of time where I/O latencies go through the roof (we're talking multiple minutes
in some cases). This causes the HBA (or the HBA driver... not 100% sure which) to decide the drive has gotten hung up, so it whacks the drive with a reset. Do this enough times and md kicks the drive from the array.
In my case, the trigger for drives falling out of the array was a script which was sweeping through a large (10s of thousands of files) directory tree, computing MD5 sums of every file. "Wait a minute, that's a read
workload... how the f*ck did that trigger bad SMR behavior?" I hear you asking. Well, I was asking myself the exact same question, and here's where it gets crazy.
For those who may not be familiar with ext4 options, there are three ways the file system can manage the "last access time" field of a file's metadata - "atime", "relatime" (which is the default these days), and "noatime". These correspond to "always update access time when a file is touched", "update access time only if last modification time is newer than currently stored last access time", and "don't update last access time". You'd think the default "relatime" setting would keep you out of trouble, at least for read-intensive workloads... but no, there's also a 24 hour timeout, where if you access (read) a file, and the currently stored last access time is more than 24 hours in the past, the access time gets updated regardless.
So with default file system options, sweeping through a directory hierarchy that hasn't been touched in the past 24 hours reading every file will generate a significant volume of random write requests to the drives, to update "last accessed time" meta-data. If you're using drive-managed SMR drives, this is VERY, VERY BAD.
In retrospect, I believe mounting the file system with "noatime" might have kept me out of trouble, but by the time I figured that out I had already replaced all of the DM004 drives in a fit of disgust/frustration. And I can't be sure that there wouldn't have still been other corner case workloads capable of triggering bad behavior.
So at least for Linux software RAID + ext4 file system, drive-managed SMR drives are in the AVOID LIKE THE FRIKKIN' PLAGUE bucket as far as I am concerned. And who knows what other file systems and workloads might be vulnerable.