Run SpinRite Backwards?

[rakosnik]

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.

 

[ColbyBouma]

Can SpinRite be run backwards?

No.

You can try setting XFER to a low value. Sometimes that keeps fragile drives from going offline.

SRPR XFER 1

 

[TProbst67]

...I have to admit, the idea of running SR "backwards" is intriguing...

 

[rakosnik]

No.

You can try setting XFER to a low value. Sometimes that keeps fragile drives from going offline.

SRPR XFER 1

How do you set the XFER to a low value? Do you have to use the command line?

 

[rakosnik]

...I have to admit, the idea of running SR "backwards" is intriguing...

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).

 

[ColbyBouma]

How do you set the XFER to a low value? Do you have to use the command line?

Yes, it is only available as a command line switch.

SRPR XFER 1

 

[Steve]

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!)

 

[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.

 

[Steve]

@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?

 

[PHolder]

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.

 

[cbrillow]

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.

 

[Steve]

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!