Running SpinRite on a SSD

[dg1261]

In rereading this thread, I don't see a direct mention of Dynastat vs SSDs. I have an oldish Samsung SSD which triggers Spinrite 6.1's Dynastat mode over a couple spots on the drive.

My understanding is that when Dynastat kicks in, it performs some wizardry like moving the drive heads a bit, but that doesn't sound like it would be applicable to SSDs. There's some mention above about "Dynastat 0" vs "Dynastat 1", but as presented it sounds like more of an optional preference just to speed up Spinrite a bit, and not specifically addressing SSDs.

Why wouldn't one use "Dynastat 0" with all SSDs as a matter of course? Is "Dynastat 1" of any benefit on an SSD?

 

[DanR]

Why wouldn't one use "Dynastat 0" with all SSDs as a matter of course?

DynaStat 0 is potentially data destructive. DynaStat 0 makes NO attempt to recover any data. It makes just 1 normal read. If that fails then all zeros are written to that area, possibly triggering reallocation if the area is not readily write-able.

Is "Dynastat 1" of any benefit on an SSD

Yes. DynaStat 1 and above WILL ATTEMPT data recovery. DynaStat 1 will make a minimal attempt to recover data. DynaStat 2 would try harder than DynaStat 1. DynaStat 3 would try harder than DynaStat 2. And so on.

Even though there are no moving heads in an SSD, SpinRite, via DynaStat 1 or above, will still try its best to recover data in a hard to read area of the SSD via multiple read attempts.

 

[dg1261]

DynaStat 0 makes NO attempt to recover any data. It makes just 1 normal read. If that fails then all zeros are written to that area, possibly triggering reallocation if the area is not readily write-able.

Ah, I see. I've been assuming that if a sector couldn't be read Spinrite would just bail, mark it "U" and move on to the next sector. The fact that it's still going to try writing is illuminating, so I can see where this could be destructive.

DynaStat 1 will make a minimal attempt to recover data. DynaStat 2 would try harder than DynaStat 1. DynaStat 3 would try harder than DynaStat 2.

Okay, I get that, but can you elaborate on what "try harder" means?

On a HDD, Spinrite would "try harder" using slightly different ways to attempt to read the sector. Spinrite evidently has a few variations it can manipulate on HDDs, but I don't think that's so with SSDs, is it?

IOW, on a SSD wouldn't "try harder" just mean reissuing the same, identical read request over and over and hoping for a different result?

 

[PHolder]

using slightly different ways to attempt to read the sector

That's an urban legend. Modern HDDs are independent single purpose computers, so all that SpinRite can do is just persistently ask it to keep trying to read a sector. SpinRite relied on using a special type of read known as a long read, which gave it access to the raw data from the drive. Most modern drives no longer support a long read, so all SpinRite can do is ask for the same data over an over, and hope something lucky happens. This kind of luck is what Dynastat relies on, whether it's an HDD or SSD. Physics being what it is, there is potentially some chance that something will be just right one time in the many that it tries... so maybe it's not all "hope and a prayer" but it will certainly be slow. By default SpinRite will spend 5 minutes on Dynastat per LBA if my memory serves.

 

[dg1261]

Thanks, guys. That gives me a little better perspective.

I do have backups of the data partition and Terabyte images of the OS partition, so I'm not really concerned with losing anything. If this induces the SSD to map out the trouble spots, I can just restore the partitions and don't have to rely on Dynastat spending a lot of time trying to recovering everything.

 

[Mervyn Haynes]

That's a urban legend. Modern HDDs are independent single purpose computers, so all that SpinRite can do is just persistently ask it to keep trying to read a sector.

I thought Steve said that it would move the read heads in at different speeds and directions to see if it just catch any data that may be very slightly on the edge of the track ( due to wear or knocks ). Is that now not the case on modern HDDs? Does it not have direct control of the read/write heads.

 

[Bplayer]

@dg1261 The reliability of that SSD may be questionable if SR completed with lots of recovered errors. It might be best to replace it. Another option would be to wipe the drive followed by full restore of the data and OS. This will validate your restore process and perform a fresh write of all data sectors. The downside is this will slightly reduce the life of the SSD.

 

[dg1261]

The reliability of that SSD may be questionable if SR completed with lots of recovered errors.

Yeah, I wouldn't trust this SSD for my main machine, but it's in an old laptop that is infrequently used these days. And that's also why I'm not too concerned with actions that would shorten the SSD's remaining life span.

Another option would be to wipe the drive followed by full restore of the data and OS.

That's my plan of action for this machine.

 

[PHolder]

Does it not have direct control of the read/write heads.

Nope... with things like NCQ ( https://en.wikipedia.org/wiki/Native_Command_Queuing ) and all the other "smart" tech in modern drives, they're way too complex to let the "user" (well really the OS on the user's behalf) have any control what-so-ever over what happens at the surface level. The hint is in the fact they call it a Logical Block Address (LBA) rather than a sector number any more. Drives can remap LBAs as they see fit, and they lie about their geometry anyway... so really nothing but the drive itself really knows what's going on. Still you could do things like request other LBAs of varying distance in hopes that a HDD will seek away and back... but you have no clue if the HDD had that data cached, and so ignores any request for a re-read.

 

[jlee]

I thought Steve said that it would move the read heads in at different speeds and directions to see if it just catch any data that may be very slightly on the edge of the track ( due to wear or knocks ). Is that now not the case on modern HDDs? Does it not have direct control of the read/write heads.

It apparently does still (this process of moving the heads past the track under test was the source of an infamous bug in SpinRite 6.0 that was fixed in 6.1). But modern drives now have servo data embedded in each track at several locations. The drive uses this servo data to accurately position the heads on the track. If it's off even by a little bit, the drive will correct. If the read still fails, the drive will do micropositioning on its own to try and zero in on the data.

 

[dg1261]

Another option would be to wipe the drive followed by full restore of the data and OS.

Just to close the loop, that was the plan I followed.

Two Spinrite Level 3 passes left a few red "U" blocks (representing, IIRC, close to 100 unreadable sectors clustered together on one partition). I then long formatted the problem partition, and restored the contents from backups. A third Spinrite pass then sailed right through the entire disk without so much as a hiccup.

And this is the Spinrite benchmark test now:

  |==========================================================================|
  |                        Samsung SSD 840 EVO 250GB                         |
  |--------------------------------------------------------------------------|
  |                    smart polling delay:   8.174 msec                     |
  |                    random sectors time:   0.101 msec                     |
  |                    front of drive rate: 554.311 MB/s                     |
  |                    midpoint drive rate: 557.228 MB/s                     |
  |                      end of drive rate: 557.747 MB/s                     |
  |==========================================================================|

I'm still leery of trusting this 8-10 yr. old SSD for my primary machine, but for this spare laptop this seems perfectly acceptable. It wouldn't surprise me if this SSD outlasts the laptop.