6 ms·

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 ave

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.

ioquatix 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'.
loeg 9y ago
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.
jldugger 9y ago
At that rate by my estimate, it'd take 324 days to actually write 14TB to disk. Probably not a great candidate for most applications.

ioquatix 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'.

loeg 9y ago

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.

jldugger 9y ago

At that rate by my estimate, it'd take 324 days to actually write 14TB to disk. Probably not a great candidate for most applications.