Hacker News Reader

Comment by ioquatix | Hacker News Reader

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.

View on HN

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".

> since the drive was already somewhat used

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?

> Why should filesystem specifics matter to the device itself?

I agree! That's why I think "drive was used" should not be a disqualifier for seeing horrible performance. Why should a former filesystem matter?

> did you rewrite

Not my drive.

A used drive might have been treated badly, have thousands of online hours etc

> 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):

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

SMR drives would benefit from TRIM / Discard support. That's what I've been speculating. Afaik SMR drives aren't using TRIM?

Proper host-aware and host-managed SMR drives have their own command set to manage zones. It's kind of like TRIM, but specific to SMR drives.

They're not for single drive applications. They belong in object storage arrays.

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.

True. My rule of thumb, anything over 4TB, 7200rpm or not - I use only for long backup. Not on production app that needs good IO speed.

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.

Reply on news.ycombinator.com