Is there a point at which slow SpinRite performance means the drive is bad?

[DanR]

Level 1 is read only, one normal, pass, no data recovery

Level 2 is data recovery. If a sector reads OK with a normal read, move on. If a sector is hard to reads try to recover the data. SpinRite can do a lot of things here, including using DynaStat. Recovered data is is written back to the drive, refreshing it.

Level 3 is drive maintenance: Read and rewrite every sector. Level 3 will also do data recovery for hard to read sectors, just like Level 2.

DynaStat 0 does no data recovery and is a way to speed up SpinRite when data recovery is not a concern by eliminating all data recovery attempts and time.

The drive in question has had a complete L3 run and a second L3 run on the first part of the drive. There were no errors. The drive should be fully refreshed and operating at normal speed.

SO . . . Yes! A normal level 1 run should tell you very quickly if this is the case.

For drives like this with no data concerns, a normal level 3 DynaStat 0 run should be the fastest way to check them out.

XFER would be used to check problematic drives that may benefit from s gentler touch, not routine drive checking. I previously suggested XFER thinking the drive may not have been happy with the 32k mode.

 

[PHolder]

Fascinating stuff, if you can share more, would really welcome it.

It's been a long time, and my memory is about as reliable as one of those HDDs that's been well used, but as I recall, the issue was the drive would hit certain problem sectors, and if the XFER size was large (the default initially, because Steve was trying to make SpinRite as fast as possible) the drive would basically just crash (as in firmware, not the heads impacting the surface.) This meant the drive became partially non-responsive, and the only recovery was a full power cycle. (A simple system reset did not recover the HDD function.) I tried all sorts of different XFER sizes, and in the end, pretty much anything at or over 10Kbytes caused this bad behaviour. Anything under that size and it never happened at all. I presume it's a firmware design defect in that specific drive... something to do with how it doesn't properly complete a large block request when it needs to attempt internal error recovery. Presumably its state machine gets out of whack, and it doesn't have any sort of a software watch dog to catch and reset it.

 

[peterblaise]

@Steve Gibson left the XFER option for edge-cases, but changed
SpinRite 6.1 in development up to Release 4 to automatically change
the XFER value dependent on the situation, where if a read and
write of 32,768 blocks reveals bad sectors to be worked on, then the
XFER value will automatically drop down to whatever is
appropriate, even the equivalent of XFER 1 .

That being said, I have found useful flexibility using various XFER
values, especially on SSDs.

- - - - -

Note also that SpinRite 6.1 WRITES to a drive during enumeration,
so even LEVEL 1 , which is a read-only task, happens AFTER a
WRITE test.

To completely prevent writing, use the SKIPVERIFY command
line option, such as:

SPINRITE SKIPVERIFY LEVEL 1

 

[brado2049]

Again, I’m not going to go through every drive, as I’m almost done with this set of 13 drives, but since we’ve had a bunch of conversation on this particular drive the last several posts, it completed, and appears to make for a great example for the ultimate question on this thread. I’m guessing there might be different interpretations. The overall question is when you have a drive with no errors or minimal errors, but processes very slow, what’s the conclusion to be drawn? The final results on this drive, which was processed using the following command line:

SPINRITE NORAMTEST LEVEL 3 DYNASTAT 0

• Graphic Status Display: runtime ~56 hours, one unrecoverable sector (or do GSD squares indicate multiple sectors?)
• Real-Time Activities: 2,823 not recoverable, no other errors
• SMART: ECC corrected 113/114, relocated sect 74/76

Given what I’ve gleaned so far (admittedly could be wrong), this seems like a usable drive. This seems like one of the many scenarios that SpinRite is built for — taking a problem drive and cleaning it up. Maybe that’s a wrong conclusion, but for you guys that have been processing drives with SpinRite for years, is this a drive you’d use or instead put through a wood-chipper?

Another thought occurred to me as well when looking at that one unrecoverable indicator on the GSD screen, and the RTA screen not recoverable count. Why are we getting stats on sectors that cannot be recovered when we are running a Level 3 with Dynastat 0, which I thought did no data recovery?

Thanks so much for your help everyone — this has been a real journey to understand all of this.

 

[peterblaise]

"... LEVEL 3 DYNASTAT 0 ... ~56 hours, one unrecoverable [ block ] ... ​

Real-Time Activities: 2,823 not recoverable, no other errors ..."​

When you have a chance, now run a LEVEL 5 DYNASTAT 0 , see if
it's 'healed'.

- - - - -

The blocks on the Graphic Status Display 72 blocks across x 14 blocks
down represent 1,008 equally proportioned parts of the total sector
count, for an example:

In my example, the total sector count is 3,907,029,167.

Divide that across 1,008 blocks means each block represents whatever
is happening in approximately 3,876,020 sectors!

Yeah, 3 billion sectors, each block represents 3 million sectors.

Wow. SpinRite has a lot to manage!

So any code displayed on a block could be from any one or more of 3
million sectors here.

Your drive has 5 billion sectors, so each block shows 5 million sectors -
approximately 5,814,021 to be approximate - of which, 2,823 were a
mess, about 0.049% of the displayed block is actually [ U ], which is
only 0.00000048% of the drive's total sectors.

Though one would think that 0.00000048% is trivial, it brings
everything to a halt when it's bad, doesn't it?

SpinRite is a wonderful thing.

;-)