Hacker News Reader

Comment by acqq | Hacker News Reader

It sounds easy but it's not: imagine you're the software controling the SSD. Before you do write you don't know if the write will succeed. Once you've written, exactly the information that gives the pointers to the valid data could be the one that is destroyed. Then the "raw" data you can access can be "out of order" but that would still be better than nothing. I can imagine that there would have to be some special "recovery mode" which would allow ythe user to rescue the data blocks even with the uncertain order, in case you are willing to piece some of them together. But almost certainly there aren't much people willing to pay for that.

"Read only" after some fixed number of writes would be safer. But then the complaints would be "why can't they just allow me to write as much as I can, I have the backup somewhere anyway." Which is also a valid wish. So it would be the best to be able if user could select the mode.

View on HN

And what about the drive that went into read-only mode, and then on reboot bricked itself? By design?

I can easily see someone having their computer lock up / etc, restarting, and losing their data. As restarting is often one of the first debugging steps for so many things.

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.

The person you are replying to is talking about a "defective by design" problem they want solved. You are explaining how this defect works.

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.

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.

Out of curiosity, I looked up SSD data recovery, and here is what one of the first Google hits had to say about it, in a prominent location.

"If your SSD has stopped working and you cannot access the data, the best thing to do is to turn it off to prevent further damage." [1]

Maybe that advice needs to be reconsidered?

[1] http://www.payam.com.au/content_common/pg-ssd-data-recovery....

As restarting is often one of the first debugging steps for so many things.

If you're the kind of person who can troubleshoot a faulty drive, then you're not the kind of person who should reboot as a first step towards debugging. Especially if you suspect a faulty drive.

I suspect that most people, when a computer freezes, don't instantaneously suspect a faulty drive. At least not before they try other things, a large chunk of which require reboots.

>It sounds easy but it's not: before you write, you don't know if the write will succeed. Once you've written, exactly the information that gives the pointers to the valid data could be the one that is destroyed.

How is that different from any other write the drive had experienced though?

Every single other previous write had a way of retrying by way of spare flash cells. That last write is fundamentally different, because there are none left.

So you keep some in reserve and go read-only when only x remain. Why auto-brick on next power cycle?

Its a solved problem (compare and swap etc)

Intel died after power cycle because of buggy Sandforce chip/firmware. Intel bullshit fairytale was post facto rationalization. There is NO UNIVERSE where bricking user product full of data is a good thing, especially if you promised read only failure mode in the documentation.

Everything else should still be fine though. And the flash that holds the pointers (redirection table for wear leveling) can be a slightly higher quality flash that lasts just a little bit longer.

When the SSD is bricked to read it's the redirection table that is corrupted. The corruption means that the random bits are wrong. Once the random bits are wrong, the redirection is wrong. If the redirection table is in the separate flash, you have to spend more flash for redirection table than for data, as that table will be heavily stressed (the redirections have to be often updated with the writes if you want good wear levelling). If you offload the part of the redirection table to the "normal flash" you're still at the beginning. Some random bits will be wrong after some write and you depend exactly on them to be able to read properly.

I would put the entire redirection table on ram, and only write it to disk (to a dedicated area) when turning off the power.

By doing that, that area will easily outlast the regular flash.

Hope you have ECC RAM :)

Also hope you never have a power outage or hard reset of any kind.

ECC RAM? Easy.

And as for power outages and hard resets, there's these nifty things known as capacitors. It only needs to last as long as is necessary to write the data to flash.

A better option would be to spend lots of time repetitively writing down the pointers in newer and newer iterations every N blocks, so that of fallback available if one block holding pointers fails.

Reply on news.ycombinator.com