Run SpinRite Backwards?

  • Release Candidate 6
    Guest:
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
    /Steve.
  • Be sure to checkout “Tips & Tricks”
    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!

    /Steve.

rakosnik

Member
Dec 15, 2021
10
1
Can SpinRite be run backwards? By that I mean instead of starting at the beginning of the drive and proceed to the end of the drive, can SpinRite begin at the end of the drive and proceed towards beginning?

I have a 2TB Western Digital Green drive that has some problems somewhere in the first 2%. I haven't yet figure out the locations any more specifically than that yet. When I run SpinRite from the beginning or at a few other locations within the first 2% the drive shutdown. But if I start SpinRite anywhere after the first 2%, SpinRite will run from there all the way to the end.

If SpinRite could run backwards, I could more precisely figure out the furthest location into the drive that the problems with this drive begins.
 
I'm not shocked that its not in there. But I don't think it would be a difficult thing to put in there (say person who wouldn't be writing the code).
The trouble is that the discs won't spin backwards. <g> (I'm kinda half serious) So there's a natural "forward" sequence to the operations. Also, drives WANT to read in a forward-going direction. When they are asked to read a block of data, they return that, but then they typically keep reading (to themselves) under the assumption that the next thing that's going to happen will be another read command for the next FORWARD block of data. So there's a strong forward bios.

All that said, SpinRite now reads with such long blocks (16 megabytes at a time for levels 3 and greater), and it's already going back to the start of the block for writes and re-read verifications, that it could run backwards without much impact. (Someone remind me to add that feature into SpinRite 7!)
 
  • Like
Reactions: SeanBZA
But backwards reads will result in a lot more head motions, and more seeks, as the drive will tend to read the next x blocks into cache internally, assuming that you almost always want to read sequentially, or write in sequence. Each read that is backwards will ,result in the cache first being looked at for dirty bits, then discard all that cache, then move the heads back roughly to the area that region of tracks is known to be on, then read whatever track actually is there. Then calculate if the offset for microstepping the head is within range, and microstep the head there, and wait for that block to come around, and read the next 32M, or whatever is the on drive cache, of data into the read memory, and from there run the decode on it, and the stripping of redundant data and verify data, then copy the valid data into the drive output buffer.

Thus for every block you would take at least 1 seek of the main head, perhaps 2 revolutions to get the head stable, another 3 or 4 to get to the correct track, wait for the actual selected LBA to come round, and then discard 64M of data in the read decoder, but only after it has been verified. Going to slow read operations on the drive down drastically, it will probably drop back to around the level of a RLL drive on a ST506N controller, 5 Mb/s transfer rate, simply from the dumping of the 64M chunks that have been read, plus the 10 revolutions wasted every read.

On a SSD similar, except that there is no wait for head motion and drive rotation, but again the reading and decoding of 64M chunks of MLC cell will take a lot of processing power and time, that ultimately is wasted, as the controller repeatedly reads, till that 64M chunk is out of bounds, the same overlapping blocks of memory to fill a buffer. Then discard the entire block aside from 4k, and step back 4k, and repeat. Lots of extra power dissipation, which might actually fail a marginal drive, but on a regular one will just severely hurt operational lifetime with the cells being repeatedly read, roughly 16000 times for every single LBA read off the drive, instead of doing 1 read for 64M of actual flash access.
 
@SeanBZA : No argument from me about any of that, Sean. I'm not suggesting that there would no impact on performance. But SpinRite 7.0 is going to have much more of a mass storage workstation profile. I plan for it to have two user interfaces: An easy to use "just get the job done" UI and an expert mode much more feature rich mode. Features such as "run backwards" would be in the expert mode UI and no one would make anyone use it. But I can see the potential benefits. And who knows what else we might discover?
 
The "logical" suggestion would be to have a way, on the command line if it were ever added to SR6.x and maybe in a UI in SR7 that the user can input block ranges in increasing or decreasing order. So I could put something like spinrite.exe 50% 20% 80% 100% to have SpinRite work on the 20%-50% range backwards then finish up doing the 80%-100% range forwards.
 
Most data recovery cloning tools (eg ddrescue or HDDSuperClone/OpenSuperClone) are able to read backwards. This effectively disables read caching. They also have the ability to skip over bad areas. Ddrescue is media agnostic, but OpenSuperClone tries to understand the serpentine nature of disc traversals and will avoid any LBA which it thinks is associated with a weak head. Since OpenSuperClone is open source, I would think that there would be an opportunity to replicate its head discovery algorithm in other tools ...
I wonder if it disables caching, I suspect sector(s) will still be passed on to a cache, I have always been somewhat puzzled by this. But using DiskPatch I (or DiskPatch users) have been able to clone drives by reading them in reverse. DiskPatch did 'dumb' in reverse clone simply reading drive from max LBA to min LBA. It's dead slow.

The advantage of reserve direction reading is that it "breaks" the drive's read ahead which could be advantageous IMO. It's the read ahead that makes things more difficult. Assume sector 455 is bad and we're reading sector 400. Drive may decide we'll read 400 + 64 more sectors (read-ahead) causing the drive to stall / mal-behave as it's trying to read this bad sector @ 455 even through we didn't ask for it. And this will then repeat if we try sector 401, 402, 403 etc.. I don't see how caching would be the problem as cache may already contain 401, 402 etc.. in our case so the drive won't have to read those again. Unless the drive's internal procedures somehow invalidate cache contents in case of some error.

Again assuming sector 455 bad, reading forward means we get troubled results for each sector lead up to LBA 455 due to read ahead as long as LBA455 is in read-ahead reach, in the worst case imaging/reading completely stalls while reading in reverse we will not have any issues until we actually reach sector 455.

LBA 445-446-447-448-449-450-451-452-453-454-455-456-457-458-459-460-461 etc. .. In effect reading in reverse will not give us more sectors per se, but it may be less troublesome. Reading in reverse still make sectors 454, 453, 452 etc. problematic assuming reading 452 will again include LBA 455. In case of SpinRite however, if we read in reverse and if we can get sector 455 to reallocate, 454, 453, 452 etc. may all of a sudden read without issue.

ddrescue etc. aside, DMDE clones/images forward however you can tell is to retry the 'read buffer', so the number of sectors you configured to be read at once, in reverse which I think makes sense as a strategy. You can avoid some of the issues with imaging in Windows (but some of those go for Linux too: OS initiated retries and time-outs) by avoiding Windows disk I/O. I think a similar strategy makes sense for SpinRite in-place repair scans.
 
Last edited:
Can SpinRite be run backwards? By that I mean instead of starting at the beginning of the drive and proceed to the end of the drive, can SpinRite begin at the end of the drive and proceed towards beginning?

I have a 2TB Western Digital Green drive that has some problems somewhere in the first 2%. I haven't yet figure out the locations any more specifically than that yet. When I run SpinRite from the beginning or at a few other locations within the first 2% the drive shutdown. But if I start SpinRite anywhere after the first 2%, SpinRite will run from there all the way to the end.

If SpinRite could run backwards, I could more precisely figure out the furthest location into the drive that the problems with this drive begins.
Maybe I’m misunderstanding something, but I’m a little puzzled over all the emphasis on running backwards, when it seems that your objective is to zero in on an area where errors start to appear. You’ve stated that problems occur between the beginning of the drive and 2%, and that there are no errors between 2% and the end. I would put a magnifying glass on that first 2% zero in with a binary search.

Why not start a 0% and stop at 1%? If there are errors in that first 1%, go back and start at 0% and stop at .5%. Conversely, if the 0% to 1% run did not produce errors, you’ve cut the potential problem area in half, and can then check the area between 1% and 2%.

Anytime you can throw out half of a defined range of data with a single test, you’re on the way to pretty quick answer to your question.
 
Maybe I’m misunderstanding something, but I’m a little puzzled over all the emphasis on running backwards, when it seems that your objective is to zero in on an area where errors start to appear.
For me, at least, it was an intellectual exercise and a bit of a lark. Since it would be trivial to add this to SR7, it was fun to explore. But I agree 100% that it would be way down on a list of future features! (y)