SSD Write Endurance 25nm Vs 34nm

[Anvil]

...
The reason its not booting up is likely that the last remaining firmware copy in your flash got corrupted beyond recoverability.
...

Are you saying that the firmware is stored in regular NAND?

--

Kingston SSDNow 40GB (X25-V)

459.96TB Host writes
Reallocated sectors : 12

MD5 OK

33.50MiB/s on avg (~84 hours)

--

Corsair Force 3 120GB

01 90/50 (Raw read error rate)
05 2 (Retired Block count)
B1 64 (Wear range delta)
E6 100 (Life curve status)
E7 13 (SSD Life left)
E9 328050 (Raw writes)
F1 436652 (Host writes)

MD5 OK

106.88MiB/s on avg (~84 hours)

power on hours : 1277

B1 has stopped decreasing, it is 2 up from last reading : from 62 to 64.

--

We are not going to change the test, the goal still is to find how long the drive can Endure writing, it is the main goal.

However, as a result of the Samsung and the m4 stopped working there is now a second goal, data retention.
It has been there all along and the m4 just confirms that we need to start looking at the phenomena.

The question is how do we validate the retention without making the test last for years and thus making the test academic and boring.

I am continuing as planned and will perform a short retention test at 500TiB on both drives, testing every 50 or 100TiB depending on speed might be what we need.

Instead of all drives going through rigorous retention testing we should start by selecting a drive (a fast drive e.g. the Samsung 470/830 or the m4) and perform more exact retention testing on that drive.
That way we can get to the core without breaking the main goal of the test.
The findings from this test can be used to specify how to perform a proper retention test.

[johnw]

Are you saying that the firmware is stored in regular NAND?

Highly unlikely. Since the firmware does not need to be written frequently, it can be stored on its own private flash that is used for nothing else.

In contrast, the metadata for the index of LBAs to flash pages is constantly changing, so it is likely written to regular flash (probably redundant copies, too) so that it can take advantage of wear leveling. If the index were written to private flash, it might wear out before the rest of the SSD's flash.

Although I can think of another strategy for writing the metadata, so I could be wrong about it being written to regular flash. The other strategy would be to devote a chunk of flash many times larger than the metadata. Then do a simple wear-leveling algorithm where each write of the metadata occurs in the next slot in the reserved flash. I'm not sure how much flash would need to be reserved, since it depends on how often the metadata gets written to flash.