I bought an 8TB shingled drive. While the initial hundreds of MB of backup files wrote at reasonable speeds, it quickly dropped down to 4-5MB/sec sustained average for the rest, until it was idle for hours to catch up. Host management probably can help, but I'm not touching another SMR drive again.
Yeah, that's the problem with drive-managed SMR — these drives are totally unusable by SMR-naive applications, so there's no point hiding it from the host. I think SMR drives have very niche application.
I guess if you use these for a log-style database, write only backup (e.g. a replacement for tapes with better random read), you'll be happy. But for a general purpose drive they suck.
What I was doing was large backups, no overwriting, and it slowed down massively. I reformatted to a linear log filesystem, and still had the same unusable performance trend. However, since the drive was already somewhat used, and the drive itself knows nothing about the filesystem but only about sectors, I'm sure it was shuffling all the old data around as well.
Strangely enough, I could imagine it might work for a primary hard drive, as writes tend to be small and bursty allowing the SMR shuffling to catch up. But installation would take days.
Marketing them as "Archive" drives as Seagate did is the absolute wrong case for these. It's impossible to get any backup/archive copied over in any timely fashion. As a live mirror which gets piecemeal changes as they happen, then maybe. But that's still not an "archive".
You are spreading a lot of FUD based on one single anecdote with a used drive. Let me counter that anecdote with my own complete satisfaction of using such drive for over a year of daily backups without anything 'taking days'.
I bought it new. It was used by me in a prior filesystem (ext4) to attempt backing up files, so the drive had actively written user sectors on it before trying out a linear log filesystem for the same backups. If instead I had used such a FS on the drive in its new state, there might have been a possibility of better performance, depending on the internal drive management software. The notion of returning it to a state where it considered sectors unused is also dependent on that software.
Why does it matter that the drive was used? If I can permanently damage my performance by using a different filesystem for a while, that's a big deal. It's not FUD to talk about how drive-managed SMR is unpredictable, and might work great or might work horribly, and you can't entirely predict what you'll get.
Why should filesystem specifics matter to the device itself? If you believe that is the case, did you rewrite the whole drive with zeros or something, or better yet use some device builtin erase function?
> I reformatted to a linear log filesystem ... I'm sure it was shuffling all the old data around as well.
I’d assume for these you should follow the same advice as SSDs, and issue the ATA Secure Erase command to have the drive wipe itself (or as is typically the case now, just it’s internal state and encryption keys):
Seagate sold (sells?) them as consumer packaged single external USB-3 drives, so at least their marketing posture doesn't promote them only for that particular use. Which is part of the problem.
This is kind of a non-sequitur. SMR drives have vastly worse performance than non-SMR drives. Neither RPM nor capacity has anything to do with SMR or non-SMR.
Higher capacity drives often have higher platter data rates, because of the increased density (or more platters & heads) at the same rotational speed. They should have better I/O throughput than 4TB drives... as long as they're not SMR. :-P A SMR drive that takes multiple days to transfer 500GB to it isn't useful as a maintained backup either.
SMR drives really aren't intended at all for single drive applications.
Get 512 of them in a giant pool (especially if it's SMR aware) and the throughput issues start to be less of a concern for certain applications. Anything write intensive of course means you immediately look elsewhere.
