On Sun, Apr 28, 2013 at 12:27 AM, Bill Ricker <bill.n1...@gmail.com> wrote: > If the disk is failing, perhaps what it needs in SpinRight to recover the > iffy blocks. Not Free, not Open, but good stuff and not expensive.
Oh boy. This is going to get into religious territory. I am of the opinion that while SpinRite is not a total scam, it's highly overrated, mostly obsolete, and all of it's useful functionality is now available in free programs elsewhere. SpinRite *may* have had some relevance back in the days of MFM, when hard drives were powered by steam and people still thought MS-DOS was a good idea, but it's not worth paying for these days. And some of the claims made by the author are bunk and always have been. SpinRite will read every block on the disk, to make sure they still can be read. This is useful. But even CHKDSK/SCANDISK will do that, and have since DOS 6, circa 1993. SpinRite will read-and-rewrite blocks. There are scenarios where this may be a plausible benefit, such as allowing the drive's built-in relocation mechanism to relocate a marginal sector. But "badblocks -n" will do the same thing, for free. SpinRite will read blocks over and over again. If a read fails, it will keep trying until it succeeds, which is useful on a failing but not dead drive. But dd_rhelp will do the same thing, for free. To read a bad block, SpinRite will try tricks like seeking to adjacent cylinders/heads/sectors and back again, in various directions. This was plausible for ancient drives, but everything made in the past 20 years or so has abstracted the real disk geometry away from the host, even when presenting "CHS". So these tricks are meaningless on anything that isn't old enough to run for congress. And, of course, SpinRite is from Steve Gibson, who always talks like an infomercial host. Billy Mays could have taken lessons from Gibson. Gibson claims SpinRite "interfaces directly to the hard disk system's hardware", which somehow gives it magical abilities. Everything I've seen suggests this is an outright lie. SpinRite flat-out won't work if the drive isn't presented using BIOS interrupt 0x13. He claims things like "hardware register level awareness of IDE and SCSI drives". SCSI drives *don't have hardware registers*. The SCSI spec is quite abstract and hides all that stuff. Further, you don't talk to a SCSI drive, you talk to a host adapter. You literally *cannot* talk directly to the drive. You can, however, request additional sense data and mode pages, which provide a wealth of useful information about the drive. In the DOS environment under which SpinRite runes, this is done through the ASPI interrupt calls. It's a useful capability, and I expect it's what SpinRite does, but it isn't the Amazing Scientific Breakthrough!!!1! Gibson claims it is. He just Read The Fscking Manual and learned how to use ASPI. I do think SpinRite did things other software wasn't doing, at the time and place it was introduced in. Even something as simple as pattern testing wasn't common in the dark ages of DOS. (Other platforms had it, but the IBM-PC was the ghetto of the computer world.) I acknowledge that. It was valuable at the time, and even today, I suppose a nicely-presented, integrated package might still have value. But that doesn't mean Gibson's bullshit doesn't stink. > (And it makes possible the Security Now! podcast.) Regardless of the efficacy of SpinRite, Steve Gibson is in way over his head when it comes to security. His habit of being uninformed and making stuff up has burned him more then once. -- Ben _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/