Drive Stopped Responding To Commands (SRPR 6.1 RC5)

  • SpinRite Release Candidate #5 Posted
    Guest:
    Another heads-up for anyone who's interested in remaining current with SpinRite as it moves from pre-release to final v6.1. The DOS executable "SRPR.EXE" now being offered by GRC's pre-release page has been updated to Pre-Release #5. Only one error was found in RC4: When the log exceeded more than 113,359 lines, the oldest lines were not being discarded from the on-screen "scroll-back" buffer. That's fixed in RC5. Otherwise, so far as anyone knows, SpinRite 6.1 is finally ready for the world. This interim FAQ page has pre-release downloading details.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.

cpuguru

Active member
Sep 25, 2020
25
3
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
 
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. (y)
 
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
 
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.
 
Last edited:
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. (y)
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!
 
  • Like
Reactions: Steve