PDA

View Full Version : Spinrite is similar to 'snake oil' ?



Peter z80.eu
April 28th, 2017, 10:41 PM
Yesterday I powered my IBM 5155 on, played a while with programs on it, and remembered CHKDSK told me there are 110KB bad clusters.
So I decided, regardless of the fact, that I didn't recognized so far any read error before, to try a run with SPINRITE II (= analyze and refresh).
After waiting 4 hours, it had reached 15% and i was bored to wait so long, so I stopped it by pressing ESC (= controlled end).
What a surprise then: Now the drive seeks unmotivated many times, and I got 250KB in bad clusters.
Also, and this is what I didn't understand, files which could be loaded without any problems now *after* the SPINRITE run aren't loaded anymore and I got read errors. I expected not to get errors in files, which I used a lot of times 'errorfree' before.
My impression is now, SPINRITE is like a stress test, and drives which seems to be working before using SPINRITE are after applying the software 'stressed', means less reliable working, especially if the drives are already getting (very) old. So from my expirience I made, SPINRITE turned it bad instead of good, compared to the condition the drive showed me before.
Is SPINRITE something like 'snake oil', and should someone better copy files to an external drive for a backup, then using, if really needed, the low level routine of the MFM controller instead (which do not 'scrub' many times on the same place), and after all, copy the files back ?

Trixter
May 1st, 2017, 06:44 PM
Correct on all counts. Welcome to Spinrite.

Spinrite's methodology was acceptable for a drive that has a few bad spots but is otherwise working fine. On a marginal drive that might be starting to fail for good, it is a stress test and can end up making things much worse. You are correct that the best thing to do is to back up everything, then use the controller's LLF utility to wipe the drive completely clean. Make sure you enter in any bad sectors that might be printed on the drive itself (contrary to Spinrite's claims, it cannot determine if a bad sector can be "returned to active use" better than the manufacturer can -- if a sectors goes bad, leave it bad).

Stone
May 1st, 2017, 07:05 PM
I've used SpinRite for over 25 years and have found that it does exactly what it claims -- a non-destructive LLF.

It won't make a bad or failing drive good again but it will take a workable drive and refresh the LLF without losing the data on it.

There's nothing magical about it. It methodically, track by track, reads and stores the data, refreshes the LLF, and then puts the data back on the newly formatted track.

Basically it's no different than if you backup a drive, LLF it, and then restore the data to it except that you don't need to do the backup or restore parts. :-)

Trixter
May 1st, 2017, 07:20 PM
There's nothing magical about it. It methodically, track by track, reads and stores the data, refreshes the LLF, and then puts the data back on the newly formatted track.


For drives that are working and need an interleave change this is fine, and what I've used it for. But for drives that are marginal, it tries to write data back to the same (failing) track, and can't, or didn't detect a failure writing it back. This is likely what happened to the OP. I've experienced his behavior about 5% of the time I've used spinrite.

Chuck(G)
May 1st, 2017, 07:26 PM
That's not what my experience has been, but it's been a long time since I used Spinrite. I've always got better results doing a LLF and then restoring content.

Trixter
May 1st, 2017, 07:48 PM
Spinrite's LLF is generally OK. It's everything else that the product marketed that was suspect. Here's a usenet critique from John Navas, someone who worked in the storage industry, about Spinrite: https://groups.google.com/forum/#!original/rec.photo.digital/_3_9_BFWSWQ/_has4Hnzi58J

Relevant portion (note the bit about what Spinrite does correctly, LLF'ing a drive+controller combo at working temperature):


Citing Steve Gibson as a source is a bit like citing a psychic as
proof that the spirit world exists. Here's a critique that I posted to
Usenet some time ago:


As I recall my first encounter with Steve Gibson was when I was
managing development for a principal disk technology manufacturer and
he was promoting an earlier version of SpinRite. At that time I had
about 15 years of experience in disk technology. My sincere efforts
to help Steve correct some of the more serious errors in what he was
saying proved to be a complete waste of time. His subsequent "hard
disks die!" campaign only compounded the problem. He was spreading
hysteria then (for his own apparent gain), and he is doing it again
now with Shields UP!


The assertion that "hard disk die!" was based on a claim that
magnetic patterns "weaken" over time, and that SpinRite could somehow
"refresh" them. If this were true, then IDE drives, which cannot be
"refreshed," would be dying all over the place, not to mention all
the old mainframe drives that had already been running steadily for
years. Furthermore, the embedded magnetic servo (used in virtually
all reasonably current disk drives) can only be written at the
factory. If it "weakened" then the drive would fail permanently --
SpinRite could not possibly help. The fact that IDE disks have not
been failing all over the place due to "weakening" and lack of
"refreshing" by SpinRite is clear evidence that the claims were
false.


(Most problems with older MFM/RLL drives that SpinRite claimed to fix
were the result of drives not being properly low-level formatted at
working temperature on the actual controller in the end user's
computer. This problem was easily solved by using the standard
low-level format in the actual controller. That SpinRite could also
correct the problem meant nothing, since all it was doing was using
the same controller.)


Worse, Steve encouraged people to use SpinRite to "recover" areas
that had been detected and marked as defective at the factory, a bad
idea that leads to more failures in the long run, since end user
controllers are not as sensitive as factory test equipment -- they
are simply incapable of the kind of thorough testing done at the
factory. Then of course SpinRite would be "needed" again to "fix"
those failures, a self-fulfilling prophecy.


As for the people that swear by SpinRite, there are lots of people
that believe in astrology, but that doesn't make it any more valid.


I suggest that those with a technical bent visit the SpinRite website
and see they can swallow such things as:


* "prevents mass storage systems from crashing" (nothing can do that)


* "sophisticated magnetodynamic physics models" (pseudo science)


* "weakest possible magnetic signals" (not real)


* "we doubt whether anyone but Steve and a handful of aliens would
even know what all this is" (no argument there)


* "Weak Bits" (no such thing)


* "gradual evolution of the drive's storage surfaces through physical
and magnetic stresses" (mumbo jumbo)


* "SpinRite is actually able to lower the amplification of the
drive's internal read-amplifier" (impossible, and after all this time
Steve apparently still does not know that data is recorded on
magnetic disks with flux reversals, not "amplitude")


* "mass storage systems need periodic preventive maintenance"
(nonsense)


* "yeah, we know, Steve's a magician with his code" (how modest)


As for all the "exclusive" SpinRite features, many if not all of them
are anything but exclusive; for example, testing disk surfaces with
worst-case data patterns goes back many years before Steve ever
thought of SpinRite. SpinRite is 80% hype, 10% dangerous, and 10%
real substance.

bobba84
May 1st, 2017, 08:21 PM
I agree with the opinions above about it being nothing more than a glorified LLF.

It never ceases to amaze me that people would risk their beloved (and valuable) data on dodgy drives. For me, if a drive shows the slightest hint of failure, I clear it and bin it (because we all have backups, don't we??)

The only exception to this is of course vintage drives, where replacements are hard to come by. But I wouldn't ever store essential data on them anyway.

Bassoonbloke
May 2nd, 2017, 12:01 AM
Hello People,

Thought i'd just add my bit about my experiences with Spinrite. I've owned and used Spinrite from version 2 to version 5 and have never had any issues with it losing data from very dodgy disks. I think it would be stupid not to save any data from a drive that was obviously in trouble first (no matter what you are going to try with it). On early versions of Spinrite for a full, thorough test and return bad patches, it could be running for many hours, but at the end you would have the same result as a low level format, test and re-install of all the original software in one go. As the version numbers go up, so the program becomes better at recognising and working with more drives, also a bit quicker.
I am currently using V5 which is very much faster and efficient and has worked with even the most difficult (old) drives and has done so reliably and without any data loss at all.
I can only, personally recommend Spinrite as an excellent program that has served me well over the years.

Alan.

Stone
May 2nd, 2017, 03:49 AM
The assertion that "hard disk die!" was based on a claim that
magnetic patterns "weaken" over time, and that SpinRite could somehow
"refresh" them. If this were true, then IDE drives, which cannot be
"refreshed," would be dying all over the place, not to mention all
the old mainframe drives that had already been running steadily for
years. Furthermore, the embedded magnetic servo (used in virtually
all reasonably current disk drives) can only be written at the
factory. If it "weakened" then the drive would fail permanently --
SpinRite could not possibly help. The fact that IDE disks have not
been failing all over the place due to "weakening" and lack of
"refreshing" by SpinRite is clear evidence that the claims were
false.Regarding this part, IDE drives ARE dying all over the place. I have encountered way more dead IDE drives than I would have thought. They just become completely inaccessible. Even DBAN can't access them. :-)

Stone
May 2nd, 2017, 03:51 AM
I agree with the opinions above about it being nothing more than a glorified LLF.Isn't that exactly what it's supposed to be? :-) :-) :-)

bobba84
May 2nd, 2017, 04:17 AM
Isn't that exactly what it's supposed to be? :-) :-) :-)

Lol, I guess. I just think he tries really hard to convince people he can magically fix bad media without actually saying it.

glitch
May 2nd, 2017, 05:25 AM
Never liked it myself, always preferred a controller LLF + restore for old MFM/RLL disks accumulating bad sectors. I've had better luck, when possible, using ddrescue on old disks for actual data recovery.

KC9UDX
May 2nd, 2017, 05:32 AM
Regarding this part, IDE drives ARE dying all over the place. I have encountered way more dead IDE drives than I would have thought. They just become completely inaccessible. Even DBAN can't access them. :-)

I've got hundreds of dead hard drives. Not one that I know of is due to anything other than mechanical or electronic (pcb) failure.

But my hundreds are still too small of a sample. Perhaps you got all the ones that died for other reasons.

Stone
May 2nd, 2017, 05:35 AM
Lol, I guess. I just think he tries really hard to convince people he can magically fix bad media without actually saying it.Ya', he seems to have more of a sales approach than actual tech but there's enough tech in SpinRite to make it a useful tool, especially for those users who don't frequent this forum, i.e., your average Joe. :-)

Stone
May 2nd, 2017, 05:37 AM
Perhaps you got all the ones that died for other reasons.Until now I had no idea you were psychic! :-)

Bassoonbloke
May 2nd, 2017, 05:37 AM
Hello People,

I think you're trying really hard to knock a piece of very good software !!
Tell me how you are going to do a low level format on a dodgy drive, but end up with a thoroughly tested drive and leave all of the software in tact and (in my experience) fully working.
If you (for instance) do not have the original software for a re-install at the end of a LLF, your software is gone (copy protection, keys etc needed to install).
Spinrite does not magically fix bad data, but it can pull data from a drive that is suffering and one that the OS / DOS is having to try hard to correct all the time. It will also check the empty patch where the data is being copied to to make sure that it is reliable instead of just copying regardless (possibly into another dodgy patch).
For restoring old systems and recovering data for important systems this software is great (by the way I have no connection with Spinrite !!).

Alan.

glitch
May 2nd, 2017, 06:33 AM
Tell me how you are going to do a low level format on a dodgy drive, but end up with a thoroughly tested drive and leave all of the software in tact and (in my experience) fully working.

I use ddrescue under Linux, when possible, and write it back out after a successful LLF + test, or drive replacement. You get an exact image of the drive, but unlike regular dd, ddrescue maintains a log and will retry bad sectors as much as you'd like. If nothing passes CRC ever it can try and build a "consensus" sector from the data it has collected. Plus at the end of the exercise you've got an exact image of the drive for backup/archive purposes, which is always a good thing. It's not the in-place LLF that SpinRIte does, but IMO it's the better option, when available.

As it happens, usually when I can't use ddrescue, I can't use SpinRite either (e.g. RQDX3 controller on a PDP-11 system).

lowen
May 2nd, 2017, 06:38 AM
I've got hundreds of dead hard drives. Not one that I know of is due to anything other than mechanical or electronic (pcb)

I have a 2.5 inch Seagate 320GB drive that, when you hook up a TTL 3.3V UART cable to the diagnostics serial port tells you it has had a fatal media error while reading the disk-resident portion of its firmware. This could be the heads have gone bad, but threads at hddguru are split on the results of swapping in a donor head assembly, with many finding bad media to be the culprit (using a known good head stack and electronics).

I've not found a proper head stack donor yet, nor do I have the money for the proper tools to do a head stack swap on this drive (they're a few hundred dollars for good ones).

Spinrite won't help, of course.

lutiana
May 2nd, 2017, 07:01 AM
My experience with Spinrite is that it has been created to re-fresh and check each sector of the drive, and when it encounters a bad sector it will attempt to move the data it can read to a good sector. Because it forces the drive to read each sector and then re-write it (at the higher level) it sort of refreshes the data by invoking the built in error recovery functions of the drive. It will also allow you to do a low level format without loosing your data, which it does well.

That said, it by it's very nature it will stress the hell out of your drive, so if the drive is failing, it will make it fail faster, but in this instance it is designed to help you recover the data by moving it to good sectors and allowing you to (after it's done) copy the data off the drive. It does not, and has never claimed to fix bad drives.

What it does, it does VERY well, but people sometimes seem to think it's some sort of magic tool that magically fixes failing drives.

Druid6900
May 2nd, 2017, 07:24 AM
Spinrite, Norton, Optune and other, "find and lock-out" type utilities, even the ones that do a safe LLF and interleaf correction are just tools. They point out a pattern and that pattern may indicate that the drive is failing.

Only physical replacement of the affected parts will do anything to extend the life of drives with deteriorating components. They are like a thermometer; it'll tell you you have a fever, but not that you have Yellow Fever.

I run a variety of tests on a hard drive that is going to go on the site and interpret the overall results as to it's condition.

lutiana
May 2nd, 2017, 07:33 AM
I forgot to mention I have used Spinrite on a failing 1Gb drive. Before spinrite I could not get the data to copy off, I kept getting read errors. So I ran Spinrite on level 4. It took several hours, but once it was done I was able to copy the data off with no issue and no data loss. The number of bad sectors on the drive had doubled, but this was merely a confirmation of the fact that the drive was dying and needed to be replaced.

From what I've heard Steve Gibson say, this is precisely what he designed Spinrite for, or at least one of the major reasons.

So I think if that if you believe Spinrite to be "snake oil" then I'd be forced to say that you don't really know what it was designed to do and are expecting too much from it.

KenEG
May 2nd, 2017, 08:08 AM
I haven't seen anyone mention this. The original post said he aborted the process after several hours. I think that ay be why he had problems with the drive after SpinRite. He didn't let it finish it's process.

Does this sound right?

Stone
May 2nd, 2017, 09:14 AM
No... you can abort SpinRite at any point without causing damage. I've killed it midway through many times, as well without incident.

lowen
May 2nd, 2017, 09:26 AM
The equivalent block level refreshing utility on Linux is the badblocks -n option. This can be triggered from the e2fsck ext2/3/4 filesystem checker by using -cc (a single -c does a read only badblocks run). For what it's worth.

KenEG
May 2nd, 2017, 10:15 AM
No... you can abort SpinRite at any point without causing damage. I've killed it midway through many times, as well without incident.

OK, thanks for the information.

lutiana
May 2nd, 2017, 10:23 AM
No... you can abort SpinRite at any point without causing damage. I've killed it midway through many times, as well without incident.

You can also start it up at any point too. So if you kill it early you can note the % and then start it up at the % the next time.

Peter z80.eu
May 2nd, 2017, 01:19 PM
What I liked to point out is, before I started Spinrite, I was able to start all programs and all DOS commands, I had no defective directory entries.
After 15% was done and I stopped Spinrite (with pressing ESC, which is allowed), I wasn't able to start all programs and many DOS commands didn't work as before. Also, I got directory entries, which I couldn't repair with CHKDSK /F.
So from my point of view, nothing good was done by Spinrite. It only destroyed my data.
Meanwhile I started LL Format using the controllers BIOS, then FDISK and FORMAT the drive, and finally copied my files back. Guess what, no errors at all except 8KB bad clusters (110KB before using Spinrite, 250KB after using Spinrite). So far I used it for 5 hours in total, different DOS games a.s.o. and it works .... so I will NOT recommend using Spinrite. At least the version I used (Spinrite II 2.0).

knightserrand
May 31st, 2017, 05:46 AM
I know this is going to seem like a boneheaded question, given that people on this thread are talking about SpinRite doing LL formatting. I'd just like to make sure, as I'm new to the software. The other night, I ran a level 4 scan with SpinRite II on a vintage HD. It discovered a few surface defects and some "Completely Unreadable" areas. Does this mean that SpinRite has automatically modified the BIOS to record those areas as "bad", and performed its low level format in place? Or is there a separate menu of SpinRite that I'm not seeing that I would use to invoke the LLF?

Further, do all level scans do a LLF?

Trixter
August 21st, 2017, 11:04 AM
It discovered a few surface defects and some "Completely Unreadable" areas. Does this mean that SpinRite has automatically modified the BIOS to record those areas as "bad", and performed its low level format in place?

Spinrite's operation for drives it can LLF is typically this:

- Try to read a track
- If every sector reads successfully:
--- write one or more patterns to the track, then read it back to see if it reads the same
----- if same, LLF track, then write track back
----- if not the same, consider it bad; write the data to free areas in the filesystem, then rewrite the filesystem to point to the new location. Mark bad sectors as bad in the filesystem.
- If one or more sectors fail during the track read, re-read several times with ECC off until it gets what it considers correct results, then follow procedure above for "consider it bad".

You can control if spinrite does a LLF by choosing the menu option "Alter spinrite operation" before doing an analysis.

The reason many consider "spinrite = snake oil" is because, while everything it does looks good on paper, it does not translate to the product's claims. If the bits are gone, the bits are gone; there is no replacement for failed backups. I had to deal with a failing ST-251 this weekend, and I got better results using ontrack to LLF the entire drive (with a non-optimal interleave, which I found interesting) and reload everything on it, than I did by running spinrite on it endlessly trying to recover data on failing rust.

DDS
August 21st, 2017, 11:43 AM
I've used Spinrite 6.0 and ddrescue to recover difficult to read data off both floppies and hard drives. Because they both come at the process from different directions and use different algorithms they each have their own strengths and weaknesses.

ddrescue first attempts to read the disk in very large chunks. If the read is successful, it moves on to the next large chunk. If not, it splits the troublesome chunk into smaller chunks and retries the smaller chunks and repeats copying and splitting. At some point a large part of the readable data has been copied and you're down to chunks the size of a physical disk block that can't be easily read. Next the program repeatedly tries to read those chunks still marked as bad. ddrescue builds a list of what's been copied and where errors have been encountered. You can restart it specifying an error log from a previous run. If you have two identical disks, such as CDROM's where the data is beginning to fade, you can read one disk until no more data can be recovered, then read the second disk using the log from the first, and ddrescue will happily fill in the holes where data was unreadable from the first copy with data from the second.

Spinrite reads the disk until it encounters an error. Then it goes into recovery mode and re-reads the troublesome block many times while building a histogram of the data read from the block. After a large number of reads, the program has built a "consensus" of what might have been written before that disk area started getting flaky. This may or not recover data where you are getting soft errors but pretty much is hopeless for hard errors.

ddrescue will recover most of the recoverable data very quickly as compared to Spinrite's linear approach, especially if you have a lot of errors toward the front of an otherwise readable disk. For this reason I always start off a recovery with ddrescue. ddrescue will also recover more data from a disk that is in the process of failing where Spinrite might hasten it's demise by beating the heck out of the first error instead of finding and copying recoverable data further along on the disk surface. I can't remember the last time I used Spinrite.

Chuck(G)
August 21st, 2017, 12:36 PM
If there's an error in a sector header (resulting in a sector not found error), neither is worth spit--even though the sector data's still there.

glitch
August 21st, 2017, 12:56 PM
ddrescue will recover most of the recoverable data very quickly as compared to Spinrite's linear approach, especially if you have a lot of errors toward the front of an otherwise readable disk. For this reason I always start off a recovery with ddrescue. ddrescue will also recover more data from a disk that is in the process of failing where Spinrite might hasten it's demise by beating the heck out of the first error instead of finding and copying recoverable data further along on the disk surface. I can't remember the last time I used Spinrite.

This is essentially the process I use on anything I can get Linux to talk to. Works pretty well.

Chuck(G)
August 21st, 2017, 02:09 PM
So essentially ddrescue = dd if=device of=file conv=noerror in Linux/Unix parlance?

glitch
August 21st, 2017, 02:21 PM
So essentially ddrescue = dd if=device of=file conv=noerror in Linux/Unix parlance?

No, it's more than that -- as DDS said, it rips through the device reading as many large blocks as it can, marking the errors. Then it goes back and splits up the blocks with errors into smaller blocks, reads what it can, and repeats. You specify a "log" file, which tells `ddrescue` what it's been successful with and what it hasn't. The log file will let you resume where you left off (e.g. need to throw the hard disk back in the freezer, don't want to leave it unattended) but it'll also improve your chances of recovery if you have several identical copies of the same media. For instance, I had several backup floppy sets from a client, neither of which was completely good. I read one set through with `ddrescue` and then ran the other through with the same log file. It ended up recovering 100% of the data, between the two sets.

DDS
August 21st, 2017, 03:44 PM
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html

The usual caveat's apply. DO NOT use the sick disk to store the rescued image or the log file. You'll only trash the data you're trying to save. Make sure the disk you're using to store the image and logfile is at least as big as the disk you're trying to recover. ddrescue will be doing a block level recovery so even empty space on the sick disk will show up on the output image.

ldkraemer
August 21st, 2017, 04:45 PM
The better Linux program is gddrescue (which has the command name: ddrescue and package name: gddrescue), and the older
not as good program is ddrescue (which has the command name: dd_rescue, and package name: ddrescue).

Here are three good reference URL's:
https://www.linuxvoice.com/ddrescue-salvage-data-from-damaged-disks/
http://www.kossboss.com/linux---dd_rescue-vs-ddrescue
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html


Larry

Chuck(G)
August 21st, 2017, 05:04 PM
But neither has any really low-level code?

For example, it's possible to recover floppy sectors that have corrupted IDAM fields by issuing a "READ TRACK" operation, which retrieves data fields and ignores the sector address headers. But I don't know of any recovery package that exploits that.

DDS
August 22nd, 2017, 03:46 AM
The better Linux program is gddrescue (which has the command name: ddrescue and package name: gddrescue), and the older
not as good program is ddrescue (which has the command name: dd_rescue, and package name: ddrescue).

Here are three good reference URL's:
https://www.linuxvoice.com/ddrescue-salvage-data-from-damaged-disks/
http://www.kossboss.com/linux---dd_rescue-vs-ddrescue
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html


Larry

We probably should have been more clear about that.

The original tool (package name ddrescue) was an ad hoc script based attempt to recover as much as possible off of the original writer's failing drive.

The improved version (package name gddrescue) is an extended and cleaned up version of the prior script's algorithm but entirely re-written in c++.

What's confusing to me and most folks is that the package name of the first program is identical to the program name of the second. I used the first version briefly before I found the second. The second is much improved IMHO. What I described above was my experience with using the second version.

To use it, search for and install package gddrescue, then call the program as ddrescue. Clear as mud?

Maybe this will help:

https://askubuntu.com/questions/211578/whats-the-difference-between-ddrescue-gddrescue-and-dd-rescue