4 ms·

TRIM and "secure erase" are mostly the same thing, but not quite. TRIM is a command the OS sends to say "hey, this data was erased, so you can now safely erase

TRIM and "secure erase" are mostly the same thing, but not quite. TRIM is a command the OS sends to say "hey, this data was erased, so you can now safely erase this block at any time", while secure erase means "erase this block right now". With TRIM the SSD firmware has the decision of when to do it, with the other it just goes and does it. As for the performance, because of how Flash technology works, it can't rewrite data, it first has to "reset" it back to the block/cell being all 1 bits, and then sets specifics bits to 0's. TRIM (and the Garbage Collection algorithms) work around this issue by allowing the SSD to reset blocks in advance, so they're always prepared for a new write. And then there are at least two more mechanisms working along to ensure the lifetime of the drive. For a good insight into what's going on with your drives, you can read the Wikipedia article, as a start: http://en.wikipedia.org/wiki/Flash_memory http://en.wikipedia.org/wiki/Flash_memory Edit: you meant "read performance" and I read just "performance". Mmmm... on old data, what might be going on is that charge leaked from some of the bits that compose your files, and the ECC algorithms have to go a greater length to correctly recompose your information -- so reads end up being slower. That's my best guess.

mjevans 11y ago
Indeed, that was my guess as well given the performance improvements re-writing the data. The facebook study also observes to another potential source for the performance variation. According to the paper on /some/ tested drives the presence of trimmed data (such as through OS updates/etc) could lead to more complicated re-mapping patterns and thus a longer tree search when finding the correct block to read. However that doesn't correlate well with the observed speed at which the backups were reading data over time. The read speed was highly variable; with an extremely slow initial portion that would likely correlate well to stable windows install files.
- cushychicken 11y ago
  dr_zoidberg's reply males a lot of sense - it sounds like you experienced a lot of basic retention and errors, which is reasonably common on modern small process NAND. Since you're executing a block erase at the device level by doing the secure erase operation. It's setting all those pages that leaked charge - and by extension, your data - back to 1s,so they're ready to be written again. I'm a little surprised that the stale time was on the order of a year. Have you experienced any other failures?

mjevans 11y ago

Indeed, that was my guess as well given the performance improvements re-writing the data. The facebook study also observes to another potential source for the performance variation. According to the paper on /some/ tested drives the presence of trimmed data (such as through OS updates/etc) could lead to more complicated re-mapping patterns and thus a longer tree search when finding the correct block to read. However that doesn't correlate well with the observed speed at which the backups were reading data over time. The read speed was highly variable; with an extremely slow initial portion that would likely correlate well to stable windows install files.

cushychicken 11y ago
dr_zoidberg's reply males a lot of sense - it sounds like you experienced a lot of basic retention and errors, which is reasonably common on modern small process NAND. Since you're executing a block erase at the device level by doing the secure erase operation. It's setting all those pages that leaked charge - and by extension, your data - back to 1s,so they're ready to be written again. I'm a little surprised that the stale time was on the order of a year. Have you experienced any other failures?