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!
Larger Font Styles
Just a quick heads-up that I've implemented larger font variants of our forum's light and dark page styles. You can select the style of your choice by scrolling to the footer of any page here. This might be more comfortable (it is for me) for those with high-resolution displays where the standard fonts, while permitting a lot of text to fit on the screen, might be uncomfortably small.
(You can permanently dismiss this notification with the “X” at the upper right.)
You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser.
I've often noticed when running Spinrite, MHDD or ddrescue on a sickly drive, it'll hang for anything up to several seconds on a single read operation. In Windows the same syndrome manifests itself as slow booting or slow operation generally.
Does anyone (@Steve included) know why it does it, and what's going on under the hood?
Does it take that long to reconstruct the data from the error correction bits in the worst case? It'd be surprising.
Or is it re-reading with servo and strobe offsets to try and get an acceptable read? But the hang corresponds to scores or hundreds of revolutions and hence read attempts.
Is it doing recalibration seeks after each try, or group of tries?
Or is it doing its own version of dynastat?
The hangs still seem to occur if Spinrite goes into dynastat - surprising since I understood Spinrite told the drive not to attempt error correction, but just to deliver the data and error correction bits as thy are, good, bad or indifferent.
This is probably the drive's internal retry processing kicking in. The drive will keep trying to read each bad sector until it succeeds, or until a set number of retries is exceeded and an error response is returned to the OS/app.
Since most drives ship from the manufacturer with the bad sectors already mapped off, I question what has happened to this drive giving you these bad sector experiences. Most such damage is unlikely to affect a single sector, especially with the current densities, so what you're possibly experiencing is that a single file being read is overlaid with multiple bad sectors, and the drive does a lot of work to try to reliably provide the file.
No matter what the case, you're living your life dangerously, and you should convince the drive to leave these bad spots behind forever if the tool (such as SpinRite will do so) or, more reliably, retire the drive permanently.
This is SpinRite doing multiple reads, instead of the drive. Basically SpinRite has told the drive not to do any retries, but just to fail, and SpinRite tries to grab and data from the failed read and try to reconstruct the bad sector's data. SpinRite SHOULD mark that sector as bad so the drive never reuses it, and then the data will be remapped to a new sector by the drive logic. (There are not an infinite supply of sectors for the remapping, so if your drive is failing, you really do need to put it into retirement mode.)
Unfortunately, SpinRite is still running through the BIOS, and many BIOSes are not as resilient about read errors as we'd like. I'll be SO RELIEVED when this behavior disappears with v6.1!