On 2013-05-01 23:58 ET, Joshua Judson Rosen wrote: > Mike Bilow <mik...@colossus.bilow.com> writes: >>> 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. >> As explained, SpinRite went directly to the hardware, which was the only >> way to bypass ECC. By the way, CHKDSK does not by default read every >> sector: the "/R" switch is required to enable that behavior, and it >> certainly could never disable ECC. >> >>> 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 was not looking for bad blocks, which are easy enough to find, >> but for "gray area" blocks that were good enough to be readable with ECC >> enabled but not good enough to be readable with ECC disabled. > But, how do you circumvent the sector-remapping that modern drives do? > > (and, if the answer is `you don't', then what is SpinRite actually > doing that's useful *today*? And haven't some of Gibson's > `direct manipulation' claims basically decayed into outright lies?)
It is possible to disable automatic sector remapping, toggling "AWRE" and "ARRE" bits on the device, but whether this is a good idea or not is a different matter. Modern drives with intelligent controllers are capable of doing in constant normal operation exactly what SpinRite did as an occasional diagnostic procedure, which is notice that a sector is weak enough for it to require ECC salvage and remap it elsewhere. Drives that support standardized reporting of such events using SMART will try to give early warning of impending failure while trying to protect data. Exactly what happens in such cases is determined by the manufacturer and tends to be correlated with the cost of the drive, the number of spare sectors held in reserve, and so forth. Even ECC algorithms can be tweaked to trade-off between capacity and redundancy, differentiating substantially identical hardware based upon its intended use for either consumer- or server-grade applications. > And what about everything that John Navas included in his critique? > > > https://groups.google.com/group/comp.dcom.xdsl/msg/9aeee32323c2978e?dmode=source&hl=en I agree with most of John Navas' technical assertions in that article. His criticisms of SpinRite's marketing hype are obviously on target, but I'm not sure any marketing copy for anything in the computer industry could survive competent technical vetting of this sort. Even in its heyday, SpinRite never made idiotic claims such as recommending that users not bother to make back-ups. I do disagree with Navas on two substantive technical points, however. First, while Navas is strictly correct that the magnetic information recorded on the media does not fade per se, it is undeniable that the media itself abrades and grows thinner, with the result that the detectable magnetic information does, in fact, weaken. This is by no means a common failure mode for drives in practice because usually they will fail due to some more likely cause long before this becomes an issue, but if a drive survives long enough it can be a problem. Of course, SpinRite could not correct this but it could detect and warn of the condition, something only possible today with SMART. Second, Navas is outright wrong in saying that the low-level format tools built into the controllers in the MFM/RLL days were comparable to SpinRite, because they were only available as destructive operations that would prepare and erase the entire drive while SpinRite was capable of doing a non-destructive low-level format of parts of the drive, usually down to the granularity of tracks. SpinRite was a consumer product designed to take into account convenience and ease of use, so periodically low-level formatting media without it would have required backing up all of the data somewhere and then restoring it -- in an era when USB external drives did not exist. Low-level formatting ceased to be a significant issue in this context once intelligent controllers moved the task to the drive, reducing ATA and SCSI controllers to doing some basic setting up, Mode Pages and the like, and then just sending a command that amounted to "format yourself." By that time, drives were designed to account for temperature variations and other environmental factors that SpinRite could address only coarsely from outside the drive, but in the MFM/RLL era that was, I believe, valuable. > And...: > >>> 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. >> This is largely true, but even so simple an action as explicitly >> flushing the cache can help. SpinRite was, again, originally intended as >> a preventative maintenance tool and took off into feature creep where it >> was marketed as a recovery tool and began to be regarded as a magic >> panacea. Its underlying theory of operation was certainly plausible and >> in my opinion correct, but it continued to be sold on its reputation >> long after it was no longer useful. Even so, in the modern era you are >> probably better off using something like "smartmontools" to initiate a >> long self-test on the device.rather than manually test-reading every >> block on a regular basis. > [...] >> Gibson has a personality, but he walks the walk as well as talks the >> talk. I've had occasion to ask him very detailed technical questions and >> he knew his stuff. Gibson's claim about interfacing directly to hardware >> with register-level awareness was absolutely true in the days of >> proprietary controllers > [...] >> Yes, SpinRite was misunderstood and overhyped, and it stuck around as a >> magic elixir for far longer than it should have, but 25 years ago it was >> a remarkably effective and prescient utilization of stone knives and >> bear skins. > In other words..., Gibson *used to* appear to know what he was talking > about, and SpinRite *was* actually not-a-scam 25 years ago, but you guys > agree that *today* it's pure snake oil? > I have no idea what SpinRite claims to do for modern drives, so I would be hesitant to venture any opinion about that. In general, I would trust that manufacturers have the best knowledge of what goes on inside their devices and what the likely failure modes will be, and SMART provides a (mostly) vendor-independent way of encapsulating that information in a practical way. Because of this, I would expect much greater benefit from running something like "smartmontools" under Linux or Windows and configuring a short self-test daily and a long self-test weekly as opposed to messing around with kludges such as "badblocks" that operate well above the logical abstractions of the device controller. -- Mike _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
