Running SpinRite on a SSD

[Akin]

Greetings all!

So, after *finally* figuring out how to force my system to boot from USB, I briefly looked around SpinRite before hving to go to work.

Wasn’t there supposed to be support for SSD drives? None of the choices mentioned SSDs… and I recall something about how using Spinrite on an SSD could be bad for it if not set to the correct level or something.

Is there a guide or something on what levels to set it for when used on an SSD?

Thanks…

 

[ColbyBouma]

What is your goal? If you want to recover data, use Level 2. If you want to refresh the performance of your SSD, run Level 3 or 4.

https://www.grc.com/sr/user-manual.htm

https://www.grc.com/sr/faq

 

[DanR]

Wasn’t there supposed to be support for SSD drives? None of the choices mentioned SSDs

Not sure what you are/are not seeing, but . . .

The initial Drive Detection screen will show all the drives that SpinRite is able to see.

The Drive Selection screen (Main menu, Option 1) will allow you to select (highlight with Up/Down arrows and tap Space bar) the drive to be scanned.

If your SSD drive is USB then your options will be very limited by the BIOS.

 

[PHolder]

I assume the poster was expecting selecting a drive to give them a warning and/or changed options when they selected a SSD--so far as I know, this is not the case.

If SSD the drive is behaving "normally", and you're not experiencing any weird/bad behaviour, you should start with a level 2. This is basically just level 1 with auto recovery enabled if something bad is encountered. (It could result in loss of data, if recovery fails, but that data was already lost anyway.)

Exercising the SSD in this way may force the drive to give itself a "tune up". It may not make any noticeable change. The only way to know is to benchmark before and after.

If level 2 didn't help, you could try a level 3. This will rewrite the entire drive once. This obviously impacts the lifetime of the SSD, but it is believed doing this once a year or so is probably worth the cost.

 

[peterblaise]

@Akin Monday at 9:41 AM "... Greetings all! So, after ​

*finally* figuring out how to force my system to boot from USB, I ​

briefly looked around SpinRite before hving to go to work. Wasn’t ​

there supposed to be support for SSD drives? None of the choices ​

mentioned SSDs… and I recall something about how using Spinrite ​

on an SSD could be bad for it if not set to the correct level or ​

something. Is there a guide or something on what levels to set it for ​

when used on an SSD? Thanks …"​

As far as I have experienced, program author @Steve Gibson
just considered a drive a drive by this point in SpinRite 6.1 development,
where drives are so self-contained, hiding their bad sectors, managing
themselves, that what type of drive didn't matter beforehand regarding
the choices someone makes on Spinrite controls.

EXCEPT perhaps a 'warning' after we make choices, not before, telling
us that some things going on inside some newfangled drives may
surprise us when compared to our prior experience of 'traditional' HDD
behavior:

\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \
X X X X X X X X X X X X X
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
/ \ / ############################################################### / \ /
X # A selected drive is RESISTANT to wholesale rewriting #X X
\ / \ #=============================================================# \ / \
\ / # SpinRite is set to operate at level 5 which writes to the # \ / \
X # device's entire storage media. But SSDs, hybrid drives & # X
/ \ # shingled magnetic recording (SMR) drives use technologies # / \ /
/ \ / # where unnecessary writing should be avoided. Use of this # / \ /
X # level can be beneficial, but it should be used sparingly. #X X
\ / \ # Until SpinRite v7.x, which should be able to selectively # \ / \
\ / # rewrite the media of these drives, it will generally be # \ / \
X # better to use level 1 or 2 with such drives. Please see # X
/ \ # "drv technology" on the 5th line of the "hardware" tab. # / \ /
/ \ / # It will indicate whether its drive is a hybrid spinning/ # / \ /
X # solid state SSD, trimmable, or shingled magnetic SMR. #X X
\ / \ #-------------------------------------------------------------# \ / \
\ / # Press Enter <+ to proceed or ESC to cancel... # \ / \
X ############################################################### X
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
/ \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ /
X X X X X X X X X X X X X
\ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \
Press Enter<+ to acknowledge this message and continue or ESC to cancel...

Notice the conflict between "should be avoided" and "can be beneficial".

That is, @Steve is saying:

SpinRite on an SSD should be avoided, but can be beneficial.​

Resolve that!

In other words, SpinRite itself can't decide; only the user can.

I have never had a data or drive failure using Level 5 on an SSD.

But I have noticed responsiveness differences within SpinRite 6.1
when 'playing' with a variety of SpinRite controls.

Some SSDs 'deal' more or less smoothly with constant end-to-end
rewriting if I change SpinRite's approach:

XFER​

​

Try XFER 1024 or XFER 2048 or XFER 4096 or any variables,
experiment, play

​

FORCEBIOS​

​

Does not use SpinRite's own ATA AHCI drivers, and drops XFER to
127 or less

​

LEVEL 4​

​

Adds a read verify in between writes, effectively 'slowing down' the
procession of a Level 3

​

Alsl try selective sectors or percentages to work on less-than the
whole drive.

See more SpinRite controls at @ColbyBouma's excellent:
https://gitlab.com/GRC-Community/spinrite-6.1-wiki/-/wikis/Command-Line

Folks can download and review my own Spinrite LOGS - donate your
logs: https://gitlab.com/GRC-Community/SpinRite-Logs

- - - - -

@PHolder Today at 4:09 AM "... level 2 ... auto recovery ... ​

could result in loss of data, if recovery fails, but that data was ​

already lost anyway ..."​

Or use the command line option NOREWRITE to tell SpinRite not to
rewrite any incomplete sector data recovery, thereby enabling the
chance to revisit the sticky sectors and try again by any means.

I also note that DYNASTAT 1 is sufficient for me, where the default
equivalent to DYNASTAT 5 never seems to get any additional data
that DYNASTAT 1 did not already retrieve, so DYNASTAT 1 may be
a time saver.

Though I'd like SpinRite to make all the right choices for me, I know
I have to take responsibility for my own decisions, and I hope I am
as informed as possible.

 

[PHolder]

Or use the command line option NOREWRITE

Peter, I appreciate you trying to peek around every corner and dig deeply into every crevice, but when a user is having UI questions, it seems probably just overwhelming to them to talk about command line features they probably don't need to know about, at least not yet.

 

[AlanD]

​

Notice the conflict between "should be avoided" and "can be beneficial".

In other words, SpinRite itself can't decide; only the user can.

I have never had a data or drive failure using Level 5 on an SSD.

I don't think the concern is that running at L5 will cause an SSD to fail, it is more than SSD's have a limited number of write cycles, and frequent running at L5 will use a number of these. Occasional use might take a day or two off the life of the drive, but frequent use could take months off.

In other words, only use L5 on SSD's IF YOU NEED TO.

 

[Akin]

What is your goal? If you want to recover data, use Level 2. If you want to refresh the performance of your SSD, run Level 3 or 4.

https://www.grc.com/sr/user-manual.htm

https://www.grc.com/sr/faq

I was hoping that each level would explain what it does, and perhaps since I'm scrolling through SSDs, it might say something like "This is an SSD, don't use Level X on it" or something.

So... level 3 or 4 sounds like what I want. What's the difference between the two? Is one better for, or worse for, SSDs?

Thanks!

 

[Akin]

I assume the poster was expecting selecting a drive to give them a warning and/or changed options when they selected a SSD--so far as I know, this is not the case.

If SSD the drive is behaving "normally", and you're not experiencing any weird/bad behaviour, you should start with a level 2. This is basically just level 1 with auto recovery enabled if something bad is encountered. (It could result in loss of data, if recovery fails, but that data was already lost anyway.)

Exercising the SSD in this way may force the drive to give itself a "tune up". It may not make any noticeable change. The only way to know is to benchmark before and after.

If level 2 didn't help, you could try a level 3. This will rewrite the entire drive once. This obviously impacts the lifetime of the SSD, but it is believed doing this once a year or so is probably worth the cost.

Okay now, that's pretty much exactly what I expected, actually. As I scroll through each individual drive, recommended actions (or warnings) would appear based on whether it's a spinning drive or SSD.

Your explanation was great. Thanks!

 

[Akin]

Okay, so, use Level 2 for routine maintenance, and then if I have any problems, use the next levels up sequentially until the problem is fixed or the drive is in the trash?

I mainly used to use SpinRite for regular maintenance on my HDDs, but after it stopped working fifteen years ago or whenever it was that modern motherboards came along, I've pretty much forgotten everything.

Thanks!

 

[ColbyBouma]

What's the difference between the two?

Level 4 does everything Level 3 does, plus a final read to make sure the write worked.

https://forums.grc.com/threads/how-long-will-spinrite-continue-to-try.1357/#post-10074

 

[peterblaise]

@Akin "... Okay, so, use Level 2 for routine maintenance, ​

and then if I have any problems, use the next levels up sequentially ​

until the problem is fixed or the drive is in the trash? I mainly used to ​

use SpinRite for regular maintenance on my HDDs, but after it ​

stopped working fifteen years ago or whenever it was that modern ​

motherboards came along, I've pretty much forgotten everything. ​

Thanks! ..."​

No.

SPINRITE LEVEL 2 ​

... is a quickie inspection and repair BUT it can lose data ... by
replacing hard-to read portions of sectors with zeros

The NOREWRITE command line option prevents the potential loss
of data, telling SpinRite to leave unreadable sectors as is, such as
in this command line instruction:

SPINRITE NORAMTEST LEVEL 2 NOREWRITE DYNASTAT 1 ​

Note: the DYNASTAT 1 command line option just reduces the retries
from the default equivalent of DYNASTAT 5 - which is five minutes of
retries per hard-to-read sector - and so, DYNASTAT 1 - which is one
minute of read retries - goes faster through a drive.

So rather than just 'up the level' from LEVEL 2 to LEVEL 3 to
LEVEL 4 to LEVEL 5 , it's imperative to understand the drive's
behavior and decide what's appropriate.

If the data is already backed up, then:

SPINRITE NORAMTEST LEVEL 3 DYNASTAT 0 ​

... may be fine, it does not try to preserve incompletely-read data, and
just 'refreshes' the total storage area for re-use.

If the data is precious, not backed up, even:

SPINRITE NORAMTEST LEVEL 5 NOREWRITE DYNASTAT 1 ​

... may not work ( I had ONE sector that still did not respond ), requiring
either giving up, or taking another path.

Totally up to the ( informed ) user to decide, as SpinRite itself cannot
make such a decision.

To 'recover' or more accurately, to 'wipe and reuse' that bad sector,
this worked for me:

SPINRITE NORAMTEST LEVEL 5 DYNASTAT 0 ​

Then there are the tweaking variables:

SPINRITE NORAMTEST LEVEL 4 FORCEBIOS DYNASTAT 1 ​

SPINRITE NORAMTEST LEVEL 4 XFER 2048 DYNASTAT 1 ​

SPINRITE NORAMTEST LEVEL 4 XFER 4096 DYNASTAT 1 ​

Such optional controls may wade into difficult-to-read sectors more
'graciously' than defaults.

It depends.

Experiment, play, learn, and try, try, try again, with different controls.

- - - - -

Note: I always use NORAMTEST because I have seen
SpinRite 6.1.8961.0 R4 behave 'differently' after a Ram Test, so I
run the Ram Test, then exit, then restart SpinRite with
NORAMTEST .

 

[Akin]

…I’ve no idea how to use a command line to run it.

I’m not having any drive issues, I’m trying to restore the maintenance use of SpinRite I used to do like fifteen years ago and back, before modern motherboards stopped it from working. I figure with regular maintenance runs, I won’t have any drive issues.

 

[DanR]

>…I’ve no idea how to use a command line to run it.

It is not quite rocket science. But it does require a bit of know-how.

One way: At the command prompt
C:\>spinrite ?
and press Enter for brief Command Line 101 documentation.

Another way: In the app go to the Main Menu, Option 5 FAQ, Sections D and E.

Using it or not is a matter of personal preference, as well as a means automating some of SpinRite's behavior. I myself do not use it very often.

 

[DanR]

Okay, so, use Level 2 for routine maintenance

Um . . . not quite.

Level 2 is for data recovery. It will only rewrite (refresh) data when data is recovered. On a drive where no data recovery is needed, Level 2 is read only.

Level 3 (or Level 4 (= L3 + a final verify read) is for drive maintenance. All sectors will be read and then rewritten thus refreshing the entire drive,

 

[Akin]

Um . . . not quite.

Level 2 is for data recovery. It will only rewrite (refresh) data when data is recovered. On a drive where no data recovery is needed, Level 2 is read only.

Level 3 (or Level 4 (= L3 + a final verify read) ) is for drive maintenance. All sectors will be read and then rewritten thus refreshing the entire drive,

But I thought with SSDs you weren’t supposed to force it to do writes unless you have to?

 

[DanR]

But I thought with SSDs you weren’t supposed to force it to do writes unless you have to?

Quite correct! That is why I use L3 judiciously and sparingly on an SSD.

Before I use L3 on an SSD I benchmark it to see where a L3 scan is most needed.

SpinRite 6.1 does a three (3) point benchmark (beginning, middle , end) of a drive. GRC's free ReadSpeed tool does a 5 point benchmark.

Armed with that info I then apply any L3 to the area(s) where it is most needed, thus sparing the rest of the SSD drive from receiving unnecessary writes.

In SpinRite 6.1, at the Before Beginning screen, pressing Tab rather than Enter will go to a screen where specific SpinRite starting and stopping points may be specified.

Steve has commented that a future SpinRite 7x version will be able to do much more precision benchmarking and then surgically apply L3 maintenance precisely and only where it is needed. But that is a ways off.

 

[Akin]

So… if I just want to run SpinRite every six months or so on my drives to reduce the risk of problems down the road, what am I supposed to do? I have two SSDs and one spinning drive. This stuff is confusing me now. I’m not an IT guy or anything.

 

[DanR]

I would benchmark them periodically to monitor their performance. Benchmarking is a read only process with no impact for an SSD. I prefer the 5 point ReadSpeed benchmark over the 3 point SpinRite 6.1 benchmark.

Then I would use L3 only when and where the benchmark results indicate a need for it. I typically only need to L3 portions of my SSD's once a year or so as the benchmark results indicate.

This thread: https://forums.grc.com/threads/results-samsung-840-series-250-gb.923/ shows the results for one of my SSD's. In the first post I ran L3 from 0 to 80% per the first benchmark, then ran a second benchmark. Awesome. In the second post the first benchmark indicated slow performance overall, so I ran L3 on the entire drive, and then benchmarked again.

Sometimes the benchmark results will require some judgement when determining when and/or where to L3.

 

[peterblaise]

@Akin "... I’ve no idea how to use a command ​

line to run it ..."​

Yeah, I suggested a configuration page inside the running SpinRite
program where we could adjust all settings, but that was probably
beyond programmer @Steve Gibson's expectations
of an 'update' from SpinRite 6 to 6.1, so, instead, some features are
controllable only by the command line.

- - - - -

Have we ever exited SpinRite and started SpinRite again?

Did we reboot, or did we type:

SPINRITE [ Enter ]​

?

If we can type:

SPINRITE [ Enter ]​

... then we can also type:

SPINRITE NORAMTEST LEVEL 4 FORCEBIOS DYNASTAT 1 NOREWRITE HASH [ Enter ]​

​

- - - - -

There are many controls that are settable inside SpinRite.

Here are some of the controls that are ONLY settable OUTSIDE
SpinRite, by using the command line:

DYNASTAT 0 to DYNASTAT 99​

​

FORCEBIOS​

XFER 1 to XFER 32768​

NOREWRITE​

HASH​

SKIPVERIFY​

Nicely summarized by @ColbyBouma at
https://gitlab.com/GRC-Community/spinrite-6.1-wiki/-/wikis/Command-Line

- - - - -

Let's revisit the opening inquiry:

@Akin "... Greetings all! So, after *finally* figuring ​

out how to force my system to boot from USB, I briefly looked ​

around SpinRite before having to go to work. Wasn’t there supposed ​

to be support for SSD drives? None of the choices mentioned SSDs ​

… and I recall something about how using Spinrite on an SSD could ​

be bad for it if not set to the correct level or something. Is there a ​

guide or something on what levels to set it for when used on an ​

SSD? Thanks ..."​

Then:

@Akin "So… if I just want to run SpinRite every ​

six months or so on my drives to reduce the risk of problems down ​

the road, what am I supposed to do? I have two SSDs and one ​

spinning drive. This stuff is confusing me now. I’m not an IT guy or ​

anything ..."​

Simplest suggestions:

Considering that SpinRite is essentially intended for DATA RECOVERY
and DRIVE MAINTENANCE, then:

If our goal is DATA RECOVERY, then SPINRITE LEVEL 2 is​

sufficient, though BACKUP ( which SpinRite does not do ) is the​

best plan.​

​

If our goal is DRIVE MAINTENANCE, then SPINRITE LEVEL 3​

is appropriate.​

"But, SSD?!?", some folks may fear 'wearing them out' with
'unnecessary' rewriting.

Then use an HDD, don't actually 'use' the SSD we own, or fear not, by
measuring: LEVEL 3 does ONE rewrite. ONE. What's to fear? If an
SSD is ONE rewrite away from dying, we probably ought to know now
so we can switch to another drive. As I wrote, I've never had an SSD
fail even under SpinRite LEVEL 5, which does 'only' TWO writes. And
I've got SSDs that 'survived' multiple LEVEL 5 runs, no problem - all
the data remained intact and readable.

So, on the one hand, I appreciate the 'theory' of limited SSD rewrite
life. On the other hand, I'm hard pressed to find even anecdotes
where anyone says and can show "... Oops, it died while I was testing
( or running SpinRite ) ...".

- - - - -

So, why all the variables?

Because I've noticed that SSDs are variable - each manufacturer's
model is different inside.

Some handle SpinRite's defaults with aplomb.

Some crawl, but, after playing with SpinRite settings, they seem to
go faster with 'adjusted' settings of SpinRite.

Hence, my recommendation is to watch and get familiar with SpinRite's
behavior when thrown at an SSD.

If it goes smoothly, cool, we're done.

If it gets sticky and pauses or struggles or argues, then there may be
settings to 'tweak' SpinRite's behavior to better suit the magical
mystery inside a specific SSD.

Sadly, no one seems to have an analytical algorithm that would clearly
prescribe any particular matching SpinRite settings.

So when an SSD misbehaves, and SpinRite struggles, I have played,
a lot, and my share the other day above at
https://forums.grc.com/threads/running-spinrite-on-a-ssd.2047/post-14904
is a concise ( ! ) summary of my hands-on successful experience.

I'll explain what I see as the ramifications of some command-line
controls:

DYNASTAT 0 to DYNASTAT 99​

The DynaStat setting is SpinRite's retry level when trying to read​

a recalcitrant sector, spending from 0 zero minutes to 99​

ninety-nine minutes. My go-to settings are DynaStat 0 zero​

minutes to just barge through and rewrite a sector, because I've​

backed up the data, and I don't care about recovering the data,​

or I use DynaStat 1 minute, where if SpinRite can't 'see' the data​

in a minute, usually taking many retries in that minute, then just​

move on, I'll deal with the problem later. In theory, DynaStat 1​

will reduce the time SpinRite takes to handle large quantities of​

'bad' sectors by 80%, getting us more quickly to an end result for​

us to analyze.​

​

FORCEBIOS​

ForceBios bypasses SpinRite's built-in speedy IDE/ATA/AHCI​

drivers, and uses the computer's own system BIOS to 'talk' to a​

drive. This slows down SpinRite, and may reduce any weird​

misbehavior or incompatibility.​

​

XFER 1 to XFER 32768​

Xfer is how much data SpinRite asks to be transferred on one​

'block'. SpinRite is limited by the BIOS and drive, but it tries to​

automatically maximize data throughput. If a drive seems​

poorly responsive, I might 'slow down' SpinRite by reducing the​

data transfer size, hoping that the drive will handle the iterative​

read and write requests more graciously if we go slower, if we​

go smaller. Xfer 1024, Xfer 2048, Xfer whatever, I've used small​

and large numbers. Maybe I'm getting the transfer block size to​

fit inside the drive's ( unknown ) cache size, or maybe I'm setting​

the transfer block size to be so big that it exceeds or bypasses​

the drive's cache, or forces the drive to handle the data transfer​

request more successfully, more smoothly. It's a guessing game.​

​

NOREWRITE​

NoReWrite tells SpinRite to NOT rewrite a sector unless it's​

been read 100% accurately. This allows an unreadable or​

incompletely readable sector to stay as is, so that we can try​

other means of data recovery later.​

​

HASH​

Hash tells SpinRite to calculate a hash value of whatever​

sector contents it has read, and export that value on exit. It​

allows us to compare the results of two SpinRite runs to see if​

the data changed. It also slows SpinRite down, another trick to​

reduce the rapidity with which SpinRite examines a drive,​

perhaps allowing a poorly-responsive drive to more successfully​

handle constant end-to-end read and write requests.​

​

SKIPVERIFY​

SkipVerify bypasses initial read and write tests during drive​

enumeration, preserving a 'fragile' drive's integrity before​

further inspection. If it takes a long time for SpinRite to​

enumerate a drive, or if initial enumeration fails altogether, that​

may be a clue that the drive needs maintenance, so we can​

skip verify, and go directly to maintenance. Also, some drive's​

are incompatible with the verify request, so skipping verify is​

appropriate on the way to data recovery and drive maintenance.​

​

LEVEL 4​

Level 4 interrupts a Level 3 read and write cycle by adding​

another read after each transfer block's final write, which slows​

down SpinRite's march through a drive, some drives seem​

more able to handle the complete rewrite, end-to-end, if it is​

done slower.​

So, those are some of my 'tweaks' to slow SpinRite down or adjust
the method, shape, and size of SpinRite's interaction with a drive,
in the hopes of best matching whatever it takes to perform the
most successful DATA RECOVERY and DRIVE MAINTENANCE.

SSDs, and a few 'old' HDDS, are weird, whimsical, iconoclastic.

And with various settings, SpinRite can be, too.

- - - - -

That's it. Backup, and play.