Storing and Retrieving Data Slowly

[matt_waterson]

Given the benefits of storing & retrieving data more slowly on optical media, I discovered that using tools that can limit the read speed of hdd copy jobs (eg. rsync) allowed me to recover otherwise unreadable data from a failing hdd recently; it's certainly not infallible but allowed me to recover a fair amount more data than I otherwise could.

I wondered if Spinrite might employ any speed limiting techniques during its sector scans?

In contrast to the insatiable focus on pushing performance boundaries, I'm also curious to know whether limiting the write speed to either an hdd or ssd may also be beneficial for long-term archival data storage, as it can be for optical media?

 

[peterblaise]

Attach a SATA3 drive as SATA1 or eve USB ( ! ) in an adapter to go slow.

- - - - -

SpinRite 6.1 can also go 1 x 512 KB sector at a time, though a drive
may work one cluster at a time, often 4 x 512 KB, see command line
XFER { 1 to 32768 }, for examples:

SPINRITE XFER 1​

​

SPINRITE XFER 4​

I also use the command line options of LEVEL 2, NOREWRITE. and
DYNASTAT 1 or DYNASTAT 0 to limit retries, to get me through
from one end to the other, and try, try, try again, over and over, only
recovering what can be recovered in each pass, often getting more
and more with each pass:

SPINRITE LEVEL 2 NOREWRITE DYNASTAT 1​

​

SPINRITE LEVEL 2 NOREWRITE DYNASTAT 0​

​

That in a batch file re-running for 2 weeks got me what I wanted from
a drive that otherwise went offline with a more aggressive LEVEL 3
[ Edit: and DYNASTAT actually threw the drive off line, also ].

Let us know if you have found other ways to enhance data recovery
while using SpinRite.

Thanks.

 

[AlanD]

I wondered if Spinrite might employ any speed limiting techniques during its sector scans?

The default setting for Spinrite is to scan the disk as fast as possible. With larger disks this is particularly welcome, and very large disks ( 16TB upwards), can take days even at the faster speeds. As long as it is getting a "good read" from the disk, it will carry on. If it gets a "bad read", it will retry multiple times until it gets a good read. If the sector is truly bad, the disk hardware should reallocate this write to a different sector and mark the original sector as bad.

 

[peterblaise]

"... If it gets a "bad read", it will retry multiple times until it gets a good read. If the sector is truly bad, the disk hardware should reallocate this write to a different sector and mark the original sector as bad ..."

... ONLY if the read is complete.

If the read is incomplete, then SpinRite default is to overwrite the
missing data.

Hence the use of the NOREWRITE command line option, and the
manual re-running of SpinRite over and over, trying again and again.

In my example:

SPINRITE LEVEL 2 DYNASTAT 0 NOREWRITE​

... the first full scan of a SATA2 750 GB 2.5" drive took ~14 hours,
and reported tons of unreadable sectors, BUT, and this is the
important part, it also reported 'fixing' tons of fixable things.

Repeating running that SpinRite command line continuously over 2
weeks brought the total scan time end-to-end to about 7 hours, still
with unreadable sectors, still 'fixing' things.

So, over the course of 2 weeks, about 7 hours of 'work' had
successfully retrieved data that continued to remain reliable.

I could leave it for another 2 weeks or more to see how far data
recovery can go on this drive, I may try that.

The meta-message to me was that with patience, and repeated
retries NOT at once, but over time, a lot more can be retrieved than
just hammering at the drive with one pass of a maximum setting of
DYNASTAT 99, for example.

What are other folks trying with 'difficult' drives?

Thanks.

 

[DanR]

In my example:

SPINRITE LEVEL 2 DYNASTAT 0 NOREWRITE

Why DynaStat 0??? It only does one (1) normal read per sector. It is not intended for data recovery!

A better approach would be: SPINRITE LEVEL 2 NOREWRITE

This would allow SpinRite to use DynaStat for maximum data recovery, but would only rewrite sectors that are fully recovered.

More data recovered. Less time consumed.

NOTE: This drive may very well have some bad unrecoverable sectors.

DynaStat 0 is normally used only when data recovery is not a concern, to eliminate unreadable/unrecoverable sectors by writing all zeros to them. If the write fails then the "bad" sector would be reallocated. End result: NO bad/unreadable sectors in use.

DynaStat 0 is NOT for data recovery!!!

In your example DynaStat 0 is a gross time waster that severely inhibits data recovery.

 

[peterblaise]

Ah, yes, DYNASTAT 0 is often part of a recommendation for barging
through a drive with no concern of recovering data, just making it
fresh and ready for next use:

SPINRITE DYNASTAT 0 LEVEL 2​

​

SPINRITE DYNASTAT 0 LEVEL 3​

​

SPINRITE DYNASTAT 0 LEVEL 5​

Not what I am doing in my example.

I was not trying to make the drive ready for reuse.

I was trying to make the drive ready to copy out the data that was
unreadable.

- - - - -

DynaStat is just a tool, and can be used or avoided for whatever
purpose.

DynaStat throws some drives off line.

SpinRite 6 was notorious for that because it has a DynaStat bug
requiring @Paul F's patch in order to use DynaStat on larger drives:

MDFYSR60 A patch to fix a SpinRite 6 bug. May 20, 2023 at 11:10 Size: 2k​

https://www.grc.com/sr/kb/B04E.htm

​

SpinRite v6.0 has always (since its first publication in 2004) had a bug which could result in an internal division overflow when DynaStat engaged for data recovery and repair on drives larger than ~549GB. This came to light near the end of the development of v6.1 (v6.0's replacement, available to all v6.0 owners at no charge). So, although v6.1 does not need this patch, we wanted to publish it to resolve a problem that v6.0 has had since its last update in 2004.​

So we got used to running SpinRite with DynaStat disabled -
DYNASTAT 0 - for many years, for the entire lifetime of SpinRite 6 on
larger drives.

And even when DynaStat does not throw a drive offline, DynaStat can
take many minutes per sector, and produce no additional results no
matter how many retries, and with the NOREWRITE command line
option preventing it from overwriting unread data, those many
minutes per sector times thousands or millions of unreadable sectors,
can take literally forever, all without making any of the incompletely
read data recoverable.

Compare a 'bad' drive under:

SPINRITE DYNASTAT 0 NOREWRITE​

​

SPINRITE DYNASTAT 1 NOREWRITE​

​

SPINRITE DYNASTAT 99 NOREWRITE​

Look at the time spent, the the recovered results.

If there no difference, then why wait for DynaStat to confirm that
DynaStat is not the tool to recover this drive, something else must
be done?

- - - - -

As mentioned, SpinRite 'recovers' data a lot - fixing 'minor' problems
all over the place, not just user data, but presumably calling on the
drive itself to fix CRC and whatever else accompanies user data.

For me, on a 'wonky' drive, I found that DYNASTAT 0 NOREWRITE
was making an incredible amount of the drive's data recoverable.

But when DynaStat throws some drives off line, it requires a manual
power-cycle, so we gotta be there to unplug and replug the drive, to
start SpinRite again, push it forward, plus we have to manually restart
on the next sector - that's a lot of work for a user to keep track of and
control - and be there the entire time.

Alternatively, the easy way is to use DYNASTAT 0, which tells SpinRite
not to do whatever seems to throw the drive off line, and so, SpinRite
can be run over and over, as mentioned, for me, for 2 weeks, starting
with less than 2 automatic sequential runs per day, finishing with
almost 4 automatic sequential runs per day, a clue to the data recovery
that SpinRite did in the process of just a LEVEL 2 read and recover
with DYNASTAT 0, and NOREWRITE of incomplete sectors - originally
taking 14 hours to read through the drive, concluding with only
taking 7 hours to read through that same drive.

And I did nothing but write the batch file and get it started.

I went away for 2 weeks, while SpinRite, and the batch file, did all the
work.

These are all just tools and adjustments on the tools.

The tools are there to be flexibly applied in whatever way works,
whatever way best suits the challenge.

And though some think of DYNASTAT 0 as not calling on one of
SpinRite's recovery schemes, DYNASTAT 0 is not just for barging
through a drive without caring about data, but when combined with
NOREWRITE, it preserves data, and yet allows complete and total
repairs of ONLY completely read sectors, and that was my goal -
recovering whatever complete data could be recovered.

So, yeah, DYNASTAT 0 can be applied a variety of ways.

To just prepare a drive for reuse:

SPINRITE DYNASTAT 0​

Or, to recover as much as possible without overwriting or going
offline or wasting time:

SPINRITE DYNASTAT 0 NOREWRITE​

Worked for me.

- - - - -

Has anyone else found tips and tricks for getting SpinRite to work on
their wonky drives?

What did you do that finally got SpinRite working?

Thanks.

 

[DanR]

NOTE: This drive may very well have some bad unrecoverable sectors.

DynaStat 0 is normally used only when data recovery is not a concern, to eliminate unreadable/unrecoverable sectors by writing all zeros to them. If the write fails then the "bad" sector would be reallocated. End result: NO bad/unreadable sectors in use.

DynaStat 0 is NOT for data recovery!!!

In your example DynaStat 0 is a gross time waster that severely inhibits data recovery.

If a drive is sensitive/touchy and goes offline when subjected to SpinRite, then a gentler touch is indeed needed. So try this:

SPINRITE LEVEL 2 NOREWRITE XFER X

For X try values such as 4096, 2048, 1024, 512, 256, etc. for a gentler touch that will allow SpinRite to use DynaStat effectively.

Important notes:

- XFER 256 is BIOS I/O speed, aka SpinRite 6.0 speed.

- NOREWRITE only rewrites sectors that are 100% recovered.

- When a 100% recovered sector is rewritten and thus refreshed, that sector will be read only for subsequent SpinRite scan runs, allowing SpinRite to concentrate on any remaining problematic sectors.

 

[peterblaise]

"... If a drive ... goes offline when subjected to SpinRite ..."

In this case, only when under DYNASTAT.

But an interesting challenge may be to see if DYNASTAT would work
on this drive with XFER 1 or other XFER value less than default..

However, as mentioned, what's the difference between DYNASTAT 1
and DYNASTAT 99 if neither retrieves any additional data anyway?

So if a drive does not respond to DYNASTAT, then DYNASTAT 0
makes sense, just skip the DYNASTAT feature altogether.

But yes, generally, as the topic of the opening to the thread suggests,
"... Retrieving Data Slowly ...", these SpinRite command line options
below cause the process of SpinRite to slow down from defaults:

FORCEBIOS​

​

XFER { 1 .. <32,768 }​

​

HASH​

... as well as outside of SpinRite, connecting the drive in a slower
interface, such as SATA1 or USB.

- - - - -

Note that SpinRite 6.1 automatically drops from the default
equivalent of as much as XFER 32768 to whatever transfer is
required by whatever sector anomolies SpinRite finds.

For example, in my wonky drive, even though it moved forward
by 32,768 blocks at a time, as soon as any such group of blocks
contained an error, SpinRite dropped to as small an equivalent an
XFER as necessary, often as small as the equivalent of XFER 1,
automatically.

And then automatically jumped back up to the equivalent of
XFER 32768 as soon as wonky sectors were passed by, and then
SpinRite contiued using the largest data transfer block size available
... until the next wonky sector, automatically repeating this change
in XFER block size over and over as SpinRite decided was necessary.

- - - - -

So, I'm just reporting how SpinRite's various functions and controls
work for me on whatever drive is at hand at the moment - 'your
mileage may vary'.

But what 'works' for others - what have you all seen?

Thanks.