• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

SSD NAND decay?

Status
Not open for further replies.
Well, it is a theoretical question as much as practical. Besides, hard drives are notoriously unreliable these days compared to a few years ago. I've had two 2TB drives die in less than a month.

Please stay away from my hard drives then... they work great for me.
besides bad luck... any statistical evidence beyond 2 drives?

I have lost 3 drives in the past 10 years... out of about 25-30

*facepalm*

ikr
 
I've been running my X25-M daily in my main rig since ~March 2010. I put OS/apps on it (except games) and haven't done a lot of tweaking. I still have a pagefile and hiberfil on the SSD. I was running for months with hybrid sleep enabled (which wrote the 4GB hiberfil every time I used S3 sleep). Disabling hybrid sleep is the only SSD "tweak" I've done to date (and the only one I recommend beyond ensuring defrag doesn't run etc..)

This morning the Intel SSD toolbox says lifetime writes are 1.74TB and the media wearout says 98. This is the first I've noticed anything other than 99, so at least I know that "it's working". So if it takes another 49 years of this use to wear down to 0% I'm more than happy. Even if we cut that by a factor of 10, I'm still happy with another 5 years out of this SSD before showing signs of trouble.

Of the vendors available at the time I purchased, I trust Intel the most to get wear leveling, cell sparing and failure modes the "most correct". In theory, NAND flash fails on erase - not read, not write. That means that the SSD controller should know that a cell has failed when it goes to do a TRIM-prompted erase on the cell, mark it bad and be done with it. In this "wearout" mode there should be no data loss.

The static data erase issue is interesting, but if a factor in real world use, I should have started seeing parts of my OS go unreadable already. I don't know what, if any, mechanisms Intel uses to move static data around. This is a factor for wear leveling too, not just self-discharge. Static files might get written once and their 3000 (or whatever) rated writes cannot factor into the overall device lifetime if they are never freed. It's in the interest of the SSD manufacturer not to let data sit stagnant in one spot to maximize device lifetime through wear leveling.

I asked in this forum about a year ago about whether a defrag once per quarter or once per year would be beneficial to make sure that no data stays stagnant in one location for too long. I seem to recall getting booed out of here because "everyone knows not to defrag an SSD". I know that's the "normal" case, but defragging would make sure that virtually every cell (special files excluded) gets exercised at least once. IMO, if you're paranoid about static data disappearing, then set a 6 month defrag schedule on the SSD and it may help.

I'd like to see someone who knows for certain produce documentation about how wear-leveling applies to static data and whether the controller definitely moves static data around once in a while both for purposes of refreshing the stale cells as well as evening wear device-wide. I've seen JEDEC specs on the flash itself, and lots of conjecture, but not much data on what Intel (and others) actually DO with the flash via the controller. The JEDEC self-discharge specs don't tell the story alone when you don't know what the controller is doing with the flash at its disposal.
 
The JEDEC self-discharge specs don't tell the story alone when you don't know what the controller is doing with the flash at its disposal.

They do give a useful minimum, though. Even if the flash is at 50% wearout (half of the P/E cycles gone), you can still expect about 5 years of data retention, even if the SSD controller does not shuffle the static data at all.
 
I'm quite tempted to write a letter to an Intel engineer or so who is familiar with NAND Flash and/or SSD controllers. Anyone got some addresses? :D
 
Well, it is a theoretical question as much as practical. Besides, hard drives are notoriously unreliable these days compared to a few years ago. I've had two 2TB drives die in less than a month.

No, they aren't. Show me some proof of this. HDDs are great for long term storage, and I have far more faith in a HDD than I would any SSD for storage and archiving.

Sounds like you've already made up your mind about what you want to do, so have at it and stop wasting our time. :rolleyes:
 
AFAIK the day when HDDs will become obsolete for data storage are still nowhere to be seen (or predicted) since our data consumption is still growing (photos, music, non-lossy formats, HD video, etc) and the price per GB of HDDs is still falling.

The theory is that all that stuff is supposed to move to the "the cloud". Unfortunately, nobody has been able to explain to me how anyone with greater storage needs than your grandma is supposed to use this magical cloud in any affordable way, given the current environment of severe ISP data caps and limited bandwidth.
 
No, they aren't. Show me some proof of this. HDDs are great for long term storage, and I have far more faith in a HDD than I would any SSD for storage and archiving.

Sounds like you've already made up your mind about what you want to do, so have at it and stop wasting our time. :rolleyes:

1) Who asked you to reply? This is my thread. If you don't like it, go away.

2) HDD's are indeed less reliable than hard drives from a few years ago. The density is causing that. This is WELL documented across the Internet.
 
2) HDD's are indeed less reliable than hard drives from a few years ago. The density is causing that. This is WELL documented across the Internet.

I'd love to see some documentation for this. *hint*

Who asked you to reply? This is my thread. If you don't like it, go away.

Oh please :rolleyes:
 
Status
Not open for further replies.
Back
Top