Re:Endurance experiment kills six consumer SSDs over 18 months
by acqq on Thursday March 12, 2015 @05:49PM
(#9194166)
You know, the drives have their own CPU and RAM, and execute their own software. The software keeps the copy of some table needed to do the proper reads in RAM and tries to update it to the flash as the response of the normal data write. The flash fails and the software gets the notification about that. The software can provide the reads from the info in RAM as long as the info remains in RAM so it enters the read-only mode. After the reboot there are only the bad bits on the flash, the RAM content is fully wiped away by the reboot.
[ Parent
| on HN ]
Re:Endurance experiment kills six consumer SSDs over 18 months
by pXMzR2A on Thursday March 12, 2015 @09:38PM
(#9195238)
The person you are replying to is talking about a "defective by design" problem they want solved. You are explaining how this defect works.
Re:Endurance experiment kills six consumer SSDs over 18 months
by TheLoneWolfling on Friday March 13, 2015 @12:17AM
(#9195647)
So have a small area of flash that's only used to dump the RAM to at EOL. I, for one, would much rather have a little bit less space available, with a better chance of not bricking at EOL, than the current situation.
Re:Endurance experiment kills six consumer SSDs over 18 months
by acqq on Friday March 13, 2015 @07:13AM
(#9196539)
Looks like a good idea to me, the question is how small the area would be. I think I've read somewhere that writing that data takes some 40 seconds on some Samsung given the write speeds around 400 MB/s which is approx 16 GB reserved for the feature of user being able to read the failed drive which notified the user long before that the declared number of counts was already spent. Somebody who actually has better (industry insider) info is welcome to correct me.