toma@tekgvs.GVS.TEK.COM (Tom Almy) (08/23/88)
I recently spent some time examining a copy of Spinrite that a coworker bought. Seeing nothing but raves for this product here, I decided to post two of my concerns. 1). The "hype" that comes with the product strongly suggests that those people who make backups are wasting their time, and that the use of Spinrite eliminates the need to make backups since Spinrite will find failing sectors first. This seems extremely foolhardy to me. There are far more ways to loose one's data than just surface degradation! I wonder how many users of this product stop making backups? (Interesting that it takes less time to do daily tape or weekly Fastback backups than it does to do a monthly Spinrite thorough analysis!) 2). This product is addictive (and not in a nice way!). The first time it is run it will take blocks marked as bad and mark them as good again! Because these block are marginal, you must run Spinrite on a regular basis to refresh and retest the sectors. Just using the program once and putting it away is riskier than never running it at all. I must admit that there is a way to prevent Spinrite from marking bad blocks as good, but you have to go out of your way to do it. ------------- As an interesting aside, nodestructive disk reformatting programs are not new. My old CP/M system's formatting program had this as an option, as well as an old TRS-80 operating system I used. I wouldn't be surprised if some of my old floppies are no longer readable because their data was never refreshed. Tom Almy toma@tekgvs.TEK.COM Standard Disclaimers Apply
pete@octopus.UUCP (Pete Holzmann) (08/24/88)
In article <3857@tekgvs.GVS.TEK.COM> toma@tekgvs.GVS.TEK.COM (Tom Almy) writes: >Seeing nothing but raves for this product here... [actually, I posted some complaints in my generally favorable review] >1). The "hype" that comes with the product strongly suggests that those people >who make backups are wasting their time, and that the use of Spinrite >eliminates the need to make backups since Spinrite will find failing sectors >first. Well, not really. It says that you don't need to do a backup before running SpinRite, since it re-formats without losing data. That's 100% true. The one really bad claim I found in an advertising blurb was "...you'll never have ANY PROBLEMS with your hard disks. GUARANTEED!" That is obviously hype. If someone interprets that as meaning that backups will never be needed, or that hard disks will never mechanically fail, they've obviously succumbed to the hype. It *would* make sense for the documentation to explain the importance of a good backup regimen, even with SpinRite in use. >(Interesting that it takes less time to >do daily tape or weekly Fastback backups than it does to do a monthly Spinrite >thorough analysis!) But you don't need to do the 'thorough analysis' more than once. Frequent 'quicky' reformats take care of the rest of the problems that may occur. >2). This product is addictive (and not in a nice way!). The first time it >is run it will take blocks marked as bad and mark them as good again! Because >these block are marginal, you must run Spinrite on a regular basis to refresh >and retest the sectors. Just using the program once and putting it away is >riskier than never running it at all. I must admit that there is a way to >prevent Spinrite from marking bad blocks as good, but you have to go out of >your way to do it. This is basically wrong. The blocks that it tests and returns to good use could hardly be classified as 'marginal'. If you read the technical documentation, you'll understand that: 1) Most of the 'bad blocks' in an old hard disk have been added by CHKDSK, due to low-level format degradation. A new low level format restores these areas 100%. There was NEVER anything wrong on the physical disk. 2) Actual surface defects on the disk will be found by the SpinRite thorough testing. It is a more intense test than drive manufacturers use for the most part! 3) On a new drive, there's a defect list. DOS just wipes out the whole track in all cases, even though there's a high probability that the actual defect is located where it won't cause any interference with data on the track. SpinRite tests the track to see if this is the case. If the defect will not interfere, it returns the track to good use. This is not 'marginal'. Finally, the 'quicky' reformat that you do frequently will find and mark new physical defects. It will NOT return anything marked bad to 'ok'. That is only done by the 'thorough' analysis. Running SpinRite once on a drive is most definitely better than never having run it at all. >Tom Almy >toma@tekgvs.TEK.COM Pete [Standard disclaimer applies: I'm just a reasonably happy customer...] -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
haugj@pigs.UUCP (Joe Bob Willie) (08/24/88)
In article <3857@tekgvs.GVS.TEK.COM> toma@tekgvs.GVS.TEK.COM (Tom Almy) writes: >2). This product is addictive (and not in a nice way!). The first time it >is run it will take blocks marked as bad and mark them as good again! Because >these block are marginal, you must run Spinrite on a regular basis to refresh >and retest the sectors. Just using the program once and putting it away is >riskier than never running it at all. I must admit that there is a way to >prevent Spinrite from marking bad blocks as good, but you have to go out of >your way to do it. this program sounds as though it suffers from adventurous stupidity. but with good intentions. ;-) a periodic media reformat seems to be a good idea. as the heads change their alignment they may move so as to position new media defects under themselves. this would cause the previously marked bad spots to no longer be at the center of the track (or close enough to cause trouble) while introducing new flaws at the same time. i plan on reformatting and running a media reliablity test in the next month or two. i would not be surprized if some of the original bad spots have become good, or if i managed to find a few new bad spots as well. -- jfh@rpp386.uucp (The Beach Bum at The Big "D" Home for Wayward Hackers) "Never attribute to malice what is adequately explained by stupidity" -- Hanlon's Razor
cdold@starfish.Convergent.COM (Clarence Dold) (08/25/88)
From article <329@octopus.UUCP>, by pete@octopus.UUCP (Pete Holzmann): > 2) Actual surface defects on the disk will be found by the SpinRite > thorough testing. It is a more intense test than drive > manufacturers use for the most part! Whoa, there! Disk Manufacturers can and generally do perform two types of test that you could never touch in the field: 1) Analog testing, to check for physical dropouts. This doesn't even use drive electronics, I don't see how you could duplicate it. 2) Reduced margin testing. Lower the write current during pattern generation, reduce read gain during pattern checking. Both of these methods yield reported defects that you will **NEVER** catch regardless of how clever your techniques might be. The only way you might see them is through media aging, which is what they are trying to predict. What you will catch are solid defects. Listen very carefully while doing the format. WD1010-001 chips would perform four retries before reporting a 'soft' error. Give up the badspots. Don't play games with the future of your data. Particularly, watch for bad spots mapped on the same head, same sector, on adjacent tracks. Radial Striation is a common defect. > 3) On a new drive, there's a defect list. DOS just wipes out the > whole track in all cases, even though there's a high > probability that the actual defect is located where it > won't cause any interference with data on the track. SpinRite > tests the track to see if this is the case. If the defect > will not interfere, it returns the track to good use. This > is not 'marginal'. There might be defects with Byte From Index greater than ~9500 that won't affect data. There are also some 'gaps' in disk data where you could ignore defects. If SpinRite CALCULATES these places, that would be great, but just field testing doesn't cut it.
pete@octopus.UUCP (Pete Holzmann) (08/25/88)
In article <663@starfish.Convergent.COM> cdold (Clarence Dold) writes: >From article <329@octopus.UUCP>, by pete@octopus.UUCP (Pete Holzmann): >> 2) Actual surface defects on the disk will be found by the SpinRite >> thorough testing. It is a more intense test than drive >> manufacturers use for the most part! >Whoa, there! >Disk Manufacturers can and generally do perform two types of test that you >could never touch in the field: > 1) Analog testing, to check for physical dropouts. This doesn't > even use drive electronics, I don't see how you could duplicate it. > 2) Reduced margin testing. Lower the write current during pattern > generation, reduce read gain during pattern checking. This is is why I left in the 'for the most part'. What disk manufacturers generally don't do is extensive worst-case pattern testing, especially with your particular controller+drive combination. Is analog testing really in common use now on shippable drives? Seems like it would be tough to correlate the analog results with cylinder/byte# info, unless the analog test is using the normal head for testing. If so, it isn't going to find between-track problems any better than a good worst-case pattern test. In general, doing your testing 'beyond spec' is something that can't be field duplicated, it is true. On the other hand... >Both of these methods yield reported defects that you will **NEVER** catch >regardless of how clever your techniques might be. The only way you might >see them is through media aging, which is what they are trying to predict. >What you will catch are solid defects. Listen very carefully while >doing the format. WD1010-001 chips would perform four retries before >reporting a 'soft' error. What SpinRite (and Disk Technician) does is disable all retries. If there is a single error somewhere on a freshly written test pattern, it marks it bad. Thus, any area of the disk that is marginal enough to be detected at *all* by the drive electronics (note that around 80 different worst case patterns are used), will be marked bad. I've got people who have been running on a SpinRite-d drive since Christmas without any additional defects showing up. That's on drives that had been in very bad shape before. Low level formats should be refreshed pretty often in any case (more than once a year, I think. SpinRite recommends every 3 months or so.) >Give up the badspots. Don't play games with the future of your data. >Particularly, watch for bad spots mapped on the same head, same sector, >on adjacent tracks. Radial Striation is a common defect. Note that not doing a low level reformat at regular intervals is more certainly bad for your data than worrying about latent defects that currently don't even cause a soft error. Thus, if you re-do the low level format as you should, you will also find any emerging latent defects. And if you *don't* redo the low level format, you'll be bitten by that problem long before the latent defects emerge! Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
ward@chinet.UUCP (Ward Christensen) (08/28/88)
Article 20129 says "Well, not really. It says that you don't need to do a backup before running SpinRite, since it re-formats without losing data. That is 100% true". Sorry, no it isn't. I used SpinRite on my AST Premium 286, and it worked fine (I got it because of a degradation of the inner tracks due to running the machine 24 hours a day, maybe the house got too warm during the day). But when I ran it on my VERY UNUSUAL PC (with dual Interface Inc external drives) I got a drive full of 6Cs. Partition block and "everything" was blown. Somehow it failed Steve's "Check if I can reformat this drive" test. Steve was more than willing to persue this with me, but I said "Aw, heck, this is a VERY rare and old drive/controller, just put a note in the README saying that you shouldn't use it on an Interface Inc Controller".