On Dec 11, 2013, at 7:07 AM, Martin <m_btrfs@xxxxxxxxx> wrote: > On 11/12/13 03:19, Imran Geriskovan wrote: > > SSDs: > >> What's more (in relation to our long term data integrity aim) >> order of magnitude for their unpowered data retension period is >> 1 YEAR. (Read it as 6months to 2-3 years. While powered they >> refresh/shuffle the blocks) This makes SSDs >> unsuitable for mid-to-long tem consumer storage. Hence they are >> out of this discussion. (By the way, the only way for reliable >> duplication on SSDs, is using physically seperate devices.) > > Interesting... > > Have you any links/quotes/studies/specs for that please? This is an eye opener: http://techreport.com/review/25681/the-ssd-endurance-experiment-testing-data-retention-at-300tb Check page 2's section "Data Retention", which glosses over unpowered data retention. But there's a test on a 200GB hashed file on one of the SSDs that fails checksum. Fails a 2nd time, but with a different checksum. And again with yet a different checksum. Then powered off for five days. And the checksum passes. Isn't that adorable? What the article doesn't say, that's rather important, is whether the drive reported a read error to the SATA driver. If not, then ECC didn't do it's job, differently, three times. If there was a read error, then that's still not good but distinctly better than the former. So the issue with unpowered data retention is that the time varies a ton based on wear. The more blocks have been written to or erased, the lower their retention time without power. I think 2-3 years right now is really optimistic seeing as > Does btrfs need to date-stamp each block/chunk to ensure that data is > rewritten before suffering flash memory bitrot? > > Is not the firmware in SSDs aware to rewrite any too-long unchanged data? My understanding, which may be wrong, is that the drive only needs power. The data doesn't need to be re-written. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
