"SpinRite" ========================================== A hard disk maintenance/diagnostic utility Reviewed by Jay T. Blocksom (76657,3375) Product: SpinRite Version: 1.2a Price: $59.95 Vendor: Gibson Research Corporation 22991 La Cadena Laguna Hills, CA 92653 (714) 830-2200 Requires: IBM PC/XT, PC/AT, or compatible computer MS-DOS/PC-DOS (Version unspecified) One (or more) hard disk drive(s) One (or more) floppy disk drive(s) Media: One 5-1/4" floppy disk. Serial #: A0031719 Review Date: August - November, 1988 ---------------------------------------------------------------------------- BACKGROUND: The IBM PC family of computers are unique in some aspects their handling of hard disks. In particular, one item that confuses many users is the fact that the DOS "FORMAT" command, when applied to a hard disk, doesn't really format the disk. Rather, The FORMAT command merely initializes the directory and File Allocation Table (FAT), of a hard disk that has already been formatted. The "real" formatting -- often called the Low Level Format (LLF) -- is done by a separate utility program, sometimes found in ROM on the controller, some- times part of the system's SETUP program, sometimes only found on the Advanced Diagnostics disk supplied to dealers. Thus, the user is rarely exposed to -- and rarely thinks about -- the actual format of his hard disk. This is in contrast to floppy disks, where a format, is a format, is a format, etc.. But, that format -- and the process of applying it -- can have a pronounced effect on the performance and reliability of a system. In particular, many (if not most) systems in use today are running with their hard disks formatted with non-optimum interleave factors; this can markedly degrade the effective data transfer rate a given system can achieve (for a more detailed discussion of interleave, see INTRLV.ARC in DL 1 of IBMHW). Further -- and probably more importantly -- it must be remembered that since the LLF is usually only done once (when the system is first set up), any subsequent damage to that format will not be cured by the DOS FORMAT command; thus, a hard disk may seem to be defective when, in reality, it is only in need of re-formatting. For these reasons, a number of utilities have been developed to allow user to test and optimize the interleave factors used on their hard disks, and to perform low-level formatting. Among those that I am aware of are Jim Bracking's "HDTest" (available in the Data Library of IBMHW as HDTST1.ARC), "Disk Technician" (a commercial product, not available to the reviewer), and the subject of this review: "SpinRite". OVERVIEW: SpinRite is a multi-function hard disk diagnostic and maintenance utility for the IBM PC family of computers. In addition to the functions mentioned above, SpinRite also performs seek testing and read/write pattern testing of hard disks. It is completely menu-driven, and is very simple to use. Among the functions of the program, two have generated much interest and dis- cussion here on IBMNET. First, SpinRite will perform a low-level format (LLF) _without_ destroying user data in the process; second, it will allow the user to measure and optimize the sector interleave of his hard disk. In and of themselves, these functions are not unique. "HDTest" also performs these functions, in addition to a wide variety of reliability and performance tests. Thus, HDTest is the logical standard of comparison, and I will use it as such in this review. USING SPINRITE: SpinRite is supplied on a single 360K floppy disk. It is not copy-protected; but because of the unusual manner in which the Gibson-supplied "configuration" routine operates, the installation instructions in the manual MUST be followed exactly. This involves using DOS's DISKCOPY command to make an exact copy of the distribution disk, then booting the system from that copy. The boot sec- tor of the distribution disk (and thus the clone of it you just made) contains an abbreviated "operating system" which automatically loads, then executes, a hidden file called CONFIGUR.IZE. This program then modifies SPINRITE.COM. Finally, you are instructed to make a bootable floppy, sans TSRs, copy the three program files (SPINRITE.COM, SPINTEST.COM, and PARK.COM) to it, and then re-boot the system from that floppy before using SpinRite. Frankly, it is a tedious process, which appears to be primarily aimed at "idiot-proofing" the program for novices. To further discourage variations from this "routine", the FAT on the distribution disk (and, again, the clone) has been "fudged" to allocate all unused space to another hidden file called FREESECT.ORS. Once the installation process has been completed and SpinRite invoked, you are presented with two screens of self-serving propaganda, then the Main Menu. There are six choices; but since one is "Terminate SpinRite", and another (Display SpinRite Information) is in essence nothing more than still another advertisement, only four are of interest. The first of these, "Quick Surface Scan", does a sequential read of each sector on the disk, to check for the grossest of errors; second is "Begin SpinRite Analysis", the gateway to the main program; third is "Alter SpinRite Operation", which allows you to modify some of the default settings -- a very important step, about which I will have more to say shortly; finally, there's "Print Full Operation Summary", which causes a number of SpinRite's screens to be sent to the printer, in the form they last appeared in, thus providing a simple (if verbose) means of recording the results of your tests. Now, about that third menu choice... one of the more unfortunate decisions that Steve Gibson made in the course of designing SpinRite was to take an "I know better" attitude toward the drive manufacturer's in-house quality-control testing. While it may be prudent to not place total faith in that testing, SpinRite goes a step further, and ignores it completely -- to the point of discarding all previously-flagged bad tracks and considering them eligible for normal use, pending the results of SpinRite's own tests. Frankly, I consider this a grave error in judgment. While much ado is made of the "recovered" disk space in the program's reports, and this does tend to impress new users, the truth of the matter is that this is a very bad idea, for several reasons: 1. - Any such "gain" in capacity is likely to be quite trivial -- on the order of 0.1% of the disk's total capacity. 2. - There is NO WAY that a software-based diagnostic can possibly be as thorough as the manufacturer's variable-threshold analog testing. While Mr. Gibson makes some spectacular claims for the "safety" of SpinRite's tests (based on the number of times each sector is tested), it should be noted that redundancy does not equal thoroughness. 3. - Except under the most unusual circumstances (such as when using certain de-fragging utilities), the selection of which physical area of the disk is to be used for a given chunk of data is not under the user's control. Therefore, all data has an equal (and more or less random) chance of landing on one of the "recovered" sectors. Given the above, the value of any "recovered" disk space is extremely dubious, at best. If that's all your data is worth, well... it's your data. But the bottom line is, why take the risk? Fortunately, you can force SpinRite to retain any existing bad track flags, thus avoiding this problem. But to do so, you must select "Alter SpinRite's Operation" from the Main Menu, EACH TIME YOU USE THE PROGRAM. This is very important, and must not be ignored -- once you "lose" the manufacturer's bad track information, SpinRite CANNOT recover it! THE TESTS: The testing was performed on a Wyse 2200, which is an IBM PC/AT-compatible system using an Intel 80286 CPU. The clock rate is switchable between 10 MHz and 6 MHz. All tests were conducted at 10 MHz. A Seagate ST-4051 (40.4 Mb formatted capacity) is the "normal" working drive. In addition, a Tandon TM-212 (10.2 Mb formatted capacity) was installed. This drive was used for the majority of initial testing (partly because it is not normally used for working storage). While this drive proved perfectly adequate for operational and speed tests, it was a little extraordinary in that it boasted an absolutely clean bad-track map from the factory, and neither SpinRite nor HDTest could find a single bad sector on it. Thus, it was not the ideal vehicle for reliability testing. After the bulk of this review was written, another drive became available -- a CMI-6640 (31.9 Mb formatted capacity), which was giving trouble in another system, and had just been replaced. This drive was installed in the above-noted system and the tests were repeated. Since an exact match for this drive was not available in the system's ROM tables, "Type 3" (615 cylinders / 6 heads) was chosen -- this is close to the actual values of 640 cylinders and 6 heads In each case the drive was initially low-level formatted by the Wyse-supplied SETUP program. The performance of the drive was then (non-destructively) tested with three different programs: CoreTest (version 2.4 and 2.8), HDTest (version 1.12) and SpinRite itself (actually, SpinTest, the standalone test utility supplied with SpinRite, which runs MUCH faster and yields identical results). This provided a baseline for further comparisons. A sample set of files (including several levels of subdirectories) was then loaded onto the drive, to provide some variety of data for the "in place" reformat feature of both SpinRite and HDTest to chew on (and for CHKDSK to later verify). This sample data set was approximately 60-80% of each drive's capacity. Then, in turn, both SpinRite and HDTest were used to re-format the drive "in place" (i.e. -- without loss of data), the performance of the drive re-tested, and the process repeated for the next drive/program combination. In addition, HDTest has the capability of doing an "initial" (or "first time) format (with- out saving data). This was tested for purposes of performance comparison. The tests are summarized in the following tables: Execution Time -- LLF, Test, and Format TM-212 CMI-6640 ====== ======== SETUP "Init HD" 1:50 4:19 SETUP "Test HD" 3:02 8:26 DOS "FORMAT" 1:11 3:23 ------ -------- Total 6:03 16:08 HDTest Defect Scan N/A 4:15 HDTest Format N/A 5:13 -------- Total 9:28 HDTest Re-format 3:29 10:15 SpinRite, Quick Scan 4:15* 12:17 SpinRite Re-format, with no testing 7:00* 19:47 with level 2 test 16:00* 45:10 with level 4 test 1:30:00* 4:30:00* Post-process Drive Performance After SETUP/DOS format -- TM-212 CMI-6640 ====== ======== CoreTest 2.4: Xfer Rate (Kb/Sec) 161.7 162.1 T-T seek (ms) 22.4 9.7 Avg. Seek (ms) 69.2 37.3 CoreTest 2.8: Xfer Rate (Kb/Sec) N/A 163.7 T-T seek (ms) N/A 9.7 Avg. Seek (ms) N/A 37.3 HDTest 1.12: Avg. Read (2 trk, ms) 118.60 117.94 Xfer Rate (Kb/Sec) 143.34 144.10 T-T seek (ms) 22.30 9.76 Avg. Seek (ms) 69.38 37.91 SpinTest 1.2: Revolutions/track 3 3 Bytes/second 174,080 174,080 After SpinRite Re-format -- TM-212 CMI-6640 ====== ======== CoreTest 2.4: Xfer Rate (Kb/Sec) 212.1 212.4 T-T seek (ms) N/A N/A Avg. Seek (ms) N/A N/A CoreTest 2.8: Xfer Rate (Kb/Sec) N/A 223.8 T-T seek (ms) N/A 9.7 Avg. Seek (ms) N/A 37.3 HDTest 1.12: Avg. Read (2 trk, ms) 102.00 100.96 Xfer Rate (Kb/Sec) 166.67 168.39 T-T seek (ms) 22.30 9.89 Avg. Seek (ms) 69.50 37.95 SpinTest 1.2: Revolutions/track 2 2 Bytes/second 261,120 261,120 After HDTest 1.12 Re-format -- TM-212 CMI-6640 ====== ======== CoreTest 2.4: Xfer Rate (Kb/Sec) 237.3 N/A T-T seek (ms) 22.4 N/A Avg. Seek (ms) 69.2 N/A CoreTest 2.8: Xfer Rate (Kb/Sec) N/A 241.4 T-T seek (ms) N/A 9.6 Avg. Seek (ms) N/A 37.3 HDTest 1.12: Avg. Read (2 trk, ms) 85.30 84.28 Xfer Rate (Kb/Sec) 199.30 201.71 T-T seek (ms) 22.30 9.78 Avg. Seek (ms) 69.49 37.93 SpinTest 1.2: Revolutions/track 2 2 Bytes/second 261,120 261,120 * - Approximate N/A - Not tested SUMMARY: The first, and most obvious, conclusion is that SpinRite is S-L-O-W. Even with pattern testing completely disabled, it took approximately twice as long to reformat each disk as HDTest, and it was even slower than the cumbersome SETUP/FDISK/FORMAT process supplied by MS-DOS. With the recommended "Level 4" pattern testing, the execution times grew astronomically. This penalty would be acceptable, if it was offset by a subsequent increase in day-to-day performance; but this is not the case. Granted, both disks per- formed better after "treatment" with SpinRite, as compared to the "stock" configuration; but HDTest was able to make significantly greater improvements, without the tremendous time consumption. SpinRite is also less than ideally convenient to use. Once the main program is started, it insists on following its "script" of operations, which can be quite lengthly. There is no way to select a single test or operation, run just that, then exit the program. As a diagnostic tool, SpinRite is very weak. Its "performance" tests are limited to interleave factor alone. The transfer rates reported are merely calculated extrapolations of that, based on the "best case" theoretical max- imum (which is, of course, never achieved in real life). And SpinRite lacks the remainder of the wide assortment of drive and controller tests that HDTest offers. Even the track/sector flagging is poorly documented, giving the user no way to know precisely WHICH tracks are being flagged. There are other limitations, as well. As pointed out in the manual, SpinRite works ONLY within existing DOS partitions, and these partitions must be less that (or equal to) 32 Megabytes in size. So, if you're running a large disk under PC-DOS 4.0 or one of the "enhanced" versions of MS-DOS (such as Compaq's or Wyse's), you're out of luck if any of your logical drives are over 32 Mb. By comparison, HDTest looks at the drive at the "physical" level, and there- fore suffers no such restriction. HDTest will also work on drives used with other operating systems, such as Xenix (and presumably, OS/2), while SpinRite is limited to DOS alone. Further there is another, related, factor which has only recently come to light. Spinrite uses the DOS File Allocation Table (FAT) to store its bad sector information, as opposed to using low-level track-flagging. This presents another problem. If the user subsequently executes a DOS-level FORMAT command, or otherwise clobbers his FAT, all bad sector information will be lost, and the entire SpinRite test/re-format operation MUST be repeated. This is downright dangerous, since you now have no "previous" bad sector map to use as a starting point. Since SpinRite offers no way of manually flagging bad tracks/sectors, if SpinRite "misses" a previously marked bad sector on this pass, you're stuck with that -- even if you kept a written record of the manufacturer's map. CONCLUSION: While SpinRite is "better than nothing", when used for the basic purpose of modifying a disk's interleave factor, it is by no means the "end all and be all" that it has been made out to be. The user should be especially cautioned against falling into the all-too-easy trap of trusting it too implicitly.