My issue with Steve Gibson is that he spews technobabble, exploiting the delta between "stuff people who work at drive manufacturers know" and "stuff computer users, even highly educated ones, know about how hard drives work", in order to sell what basically amounts to a commercial version of badblocks with a bunch of fancy graphical animations.
Spinrite kinda worked back in the days of MFM drives where they had to be low-level formatted with sector track information the controller then uses to figure out where the head is on the drive, and that sector information is refreshed during writes. But it was still quasi-snake oil, using a lot of mumbojumbo to say "I just note the original value of a sector, write it a zillion times, and then move to the next. This causes the MFM controller to refresh the sector tracks." Yes, those drives did benefit from low-level formats done in the condition the drive would be operated in - with that particular controller, at that temperature range.
He claimed that spinrite could detect not just whether a particular bit was a 0 or 1, but get the analog value directly from the drive by "bypassing" the BIOS to talk to the controller directly. And Spinrite used to have an ASCII "graph showing these supposed values.
Post MFM - IDE, SCSI, SATA, FC, etc - controllers are built-in to the drive, and low level formatting was handled by the drive's controller itself. The drive is sent a low-level format command. Gibson might have still had some claim to legitimacy left there.
But then...drives shifted to using servo tracks written at the factory. The drive itself is physically incapable of doing anything to those servo tracks, and if you degauss the drive, you permanently destroy the drive because the servo tracks are wiped. The drive certainly doesn't expose via its IDE/SATA/SCSI interface any of the super-duper-low-level stuff he continued to claim to be accessing.
He kept spewing the same nonsense...that his utility would boost the strength of the analog 'signal' on the drive by writing it a whole bunch.
People who worked at drive manufacturers tried to work with Gibson because they were under the impression that he simply hadn't kept up with changes in hard drive technology, when the reality was (probably) that his product was snake oil and he knew it, or he was deluding himself. Example: https://radsoft.net/news/roundups/grc/20060123,00.shtml
Any value Spinrite has is achieved via simply trying to read the same data over and over. If there's a failing block, the drive will remap it, and boom, your not-quite-fully-failed drive is "working" again. Huzzah! Except...you can do the exact same thing by simply running badblocks - free and open source - or if you're trying to recover data, use ddrescue or one of its variants, also all open source. It's basically a "dd" that doesn't give up - hoping that the drive might successfully read a particular area if you try enough. The better variants use a binary search to try and get every possible sector. I've used it, and it works well - I've had drives where I was able to get everything except well less than 1MB worth of data, if you gave it enough time to run.
These days he's even claiming that Spinrite can improve SSD performance by repeatedly reading/writing data, which is absurd. All that is happening is Spinrite is a)wearing out the flash and b)maybe influencing what drive sectors are migrated to the SSD's SLC cache (most drives use an area of flash configured as SLC as a cache for reads/writes because it's significantly faster and more wear tolerant than areas configured as MLC, TLD, or QLC.) As a flash cell's electrical charge is reduced with each read, flash controllers automatically refresh a flash cell when necessary when a sector is read.
So, your takedown is "it does things you can do with badblocks"? Not everybody wants to use command line application that can't interpret large integers properly, some people prefer nice user interface and active developer that can work with larger hard drives.
> he's even claiming that Spinrite can improve SSD performance by repeatedly reading/writing data, which is absurd.
Is it really so absurd if it works? Did you do some careful tests of Spinrite on SSDs and did you find it never improved their performance? You seem to be describing 1) your mental model of the SSD drive, and 2) your belief that this model prevents Spinrite from working as advertised. How it prevents that? If SSD firmware does relocate data to other cells when read problems are detected, or refresh the cell charge where the data is, why performance can't improve?
Spinrite kinda worked back in the days of MFM drives where they had to be low-level formatted with sector track information the controller then uses to figure out where the head is on the drive, and that sector information is refreshed during writes. But it was still quasi-snake oil, using a lot of mumbojumbo to say "I just note the original value of a sector, write it a zillion times, and then move to the next. This causes the MFM controller to refresh the sector tracks." Yes, those drives did benefit from low-level formats done in the condition the drive would be operated in - with that particular controller, at that temperature range.
He claimed that spinrite could detect not just whether a particular bit was a 0 or 1, but get the analog value directly from the drive by "bypassing" the BIOS to talk to the controller directly. And Spinrite used to have an ASCII "graph showing these supposed values.
Post MFM - IDE, SCSI, SATA, FC, etc - controllers are built-in to the drive, and low level formatting was handled by the drive's controller itself. The drive is sent a low-level format command. Gibson might have still had some claim to legitimacy left there.
But then...drives shifted to using servo tracks written at the factory. The drive itself is physically incapable of doing anything to those servo tracks, and if you degauss the drive, you permanently destroy the drive because the servo tracks are wiped. The drive certainly doesn't expose via its IDE/SATA/SCSI interface any of the super-duper-low-level stuff he continued to claim to be accessing.
He kept spewing the same nonsense...that his utility would boost the strength of the analog 'signal' on the drive by writing it a whole bunch.
People who worked at drive manufacturers tried to work with Gibson because they were under the impression that he simply hadn't kept up with changes in hard drive technology, when the reality was (probably) that his product was snake oil and he knew it, or he was deluding himself. Example: https://radsoft.net/news/roundups/grc/20060123,00.shtml
Any value Spinrite has is achieved via simply trying to read the same data over and over. If there's a failing block, the drive will remap it, and boom, your not-quite-fully-failed drive is "working" again. Huzzah! Except...you can do the exact same thing by simply running badblocks - free and open source - or if you're trying to recover data, use ddrescue or one of its variants, also all open source. It's basically a "dd" that doesn't give up - hoping that the drive might successfully read a particular area if you try enough. The better variants use a binary search to try and get every possible sector. I've used it, and it works well - I've had drives where I was able to get everything except well less than 1MB worth of data, if you gave it enough time to run.
These days he's even claiming that Spinrite can improve SSD performance by repeatedly reading/writing data, which is absurd. All that is happening is Spinrite is a)wearing out the flash and b)maybe influencing what drive sectors are migrated to the SSD's SLC cache (most drives use an area of flash configured as SLC as a cache for reads/writes because it's significantly faster and more wear tolerant than areas configured as MLC, TLD, or QLC.) As a flash cell's electrical charge is reduced with each read, flash controllers automatically refresh a flash cell when necessary when a sector is read.