Drive Stopped Responding To Commands (SRPR 6.1 RC5)

[cpuguru]

Ran SRPR 6.1 RC5 on a used (by me) Samsung SSD 850 EVO 1TB on level 2 before I installed it in an iMac since it's such a pain to remove the screen to get to the innards.

Got an error that "This drive has stopped responding to commands" red screen indicating it had issues 20.5% into the run.

I tried to run it again on level 1 but SR couldn't find the drive again.

I had to power the PC off and back on again before it saw the drive.

Running SR on level 1 from the beginning and it passed that location without error and is almost done.

I'll run it again on level 2 to see if it craps out again.

Cheers!

Doug

 

[Steve]

Thanks for your report. My guess is that SpinRite helped the drive to find a read problem which it then dealt with. But that SpinRite and/or the drive did not gracefully recover from that trouble. We've seen this with spinners in the past, and it recently surfaced again for one of SpinRite's testers in GRC's development newsgroup. So I currently have it on my (very short) list of things to pursue before we finally put SpinRite v6.1 to bed. I'd be pretty certain that the same Level 2 pass tht glitched that first time will now cruise right through since that follow-up Level 1 had no trouble.

 

[fzabkar]

I would backup the data ASAP. Whilst I'm not a true believer, I think certain scenarios involving SSDs may actual benefit from SpinRite (although there are free tools to do the same thing). I'm referring to refreshing those cells that have been affected by charge bleed. In fact it would appear that some SSD makers deal with bad NAND by preemptively detecting and refreshing weak blocks, thereby hiding the problem from the user.

Samsung 840 EVO - how to easily lose your data forever:
https://forum.acelab.eu.com/viewtopic.php?f=227&t=8735

 

[magnificent_starfish]

In fact it would appear that some SSD makers deal with bad NAND by preemptively detecting and refreshing weak blocks, thereby hiding the problem from the user.

I think most modern drives will. Maybe not 'at random', but from what I have read drives will try detect data most-at-risk and refresh that by rewriting. Just doing random refreshes will eat up p/e cycles. So it's wise but you do want to limit it somehow.

And I agree and have argued before, it's something SR can be useful for. Since the effect is measurable, a future version may for example try reading, measure time it takes the drive to respond and then decide if a refresh would be useful or not. Some have suggested to TRIM afterwards but I think you don't even need to. Say we measure time it takes for the drive to deliver block of m sectors at LBA m, we decide to refresh and write back block to LBA m, the drive already knows it can garbage collect the physical addresses previously associated with LBAm-n.

Note this is meant as a generic comment and not in response to OP.

 

[cpuguru]

Thanks for your report. My guess is that SpinRite helped the drive to find a read problem which it then dealt with. But that SpinRite and/or the drive did not gracefully recover from that trouble. We've seen this with spinners in the past, and it recently surfaced again for one of SpinRite's testers in GRC's development newsgroup. So I currently have it on my (very short) list of things to pursue before we finally put SpinRite v6.1 to bed. I'd be pretty certain that the same Level 2 pass tht glitched that first time will now cruise right through since that follow-up Level 1 had no trouble.

You are correct sir - level 1 completed without issue. Ran a Level 3 and it also completed without issue.

I know it's frowned upon to write to SSDs if you don't have to but the fact that the SSD survived the level 3 process gives me more confidence that it'll be a good replacement for the bad spinner in the iMac. If it dies it dies, not a super critical system for me.

Cheers!