3 ms·

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

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.

pavs 9y ago
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.
- white-flame 9y ago
  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.
  - phil21 9y ago
    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.
- loeg 9y ago
  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.
white-flame 9y ago
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".
- Sami_Lehtinen 9y ago
  SMR drives would benefit from TRIM / Discard support. That's what I've been speculating. Afaik SMR drives aren't using TRIM?
  - baobrien 9y ago
    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.
- lucaspiller 9y ago
  > 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 https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
- mynewtb 9y ago
  > 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'.
  - white-flame 9y ago
    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.
  - Dylan16807 9y ago

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.

pavs 9y ago

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.

white-flame 9y ago
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.
- phil21 9y ago
  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.
loeg 9y ago
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.

white-flame 9y ago

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

Sami_Lehtinen 9y ago
SMR drives would benefit from TRIM / Discard support. That's what I've been speculating. Afaik SMR drives aren't using TRIM?
- baobrien 9y ago
  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.
lucaspiller 9y ago
> 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 https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
mynewtb 9y ago
> 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'.
- white-flame 9y ago
  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.
- Dylan16807 9y ago