mark@gizzmo.UUCP (mark hilliard) (03/23/88)
A lot of people have recently asked questions in unix-pc.general concerning the bad block problem on the hard disk of the UNIX PC system. Objective Programming Incorporated sells a product which, among other functions, handles this problem: "Objective Utilities". To lend some light on this issue, the following is an excerpt from pages 37 and 38 of the documentation manual for Objective Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . - 37 - 12. Bad blocks on the hard disk of a UNIX system Most hard disks have a few "bad" spots: little areas on their surfaces where the magnetic material does not respond properly to the magnetization flux they are being subjected to. These bad spots translate into "bad blocks" after initialization and formatting of the hard disk. These bad blocks can be found on brand new hard disks, and they sometimes spontaneously arise with use on older ones due to general aging and a variety of other causes, even if they weren't there at the time of manufacture. Though the system, on initialization of the hard disk, does have a "burn-in" surface-testing feature which is supposed to remove such blocks and put them on the disk's "bad block table", sometimes the repeated execution of this feature (which is usually recommended by the manufacturer) results in many good blocks being thrown out to the disk bad block table (and permanently removed from the system) along with the bad ones, while many blocks on the hard disk which later prove a problem are not caught at all at this time. A bad block in the wrong place at the wrong time can prove a disaster for your system. Its errors pop up at random, causing executions to bomb, data to be lost or inadvertently modified, reboots and prints and floppy reads to fail, unexpected race conditions to occur, and a truly bizarre array of other problems, all of which are totally unpredictable. Part of the problem here is that some blocks, containing a crucial piece of system software, might be accessed a 1000 times per day for a given software load, while others might be accessed barely once a week. Therefore, a block that is perfectly good under certain circumstances can become "bad" when it sees heavy duty under other circumstances ... and vice versa when it sees light duty. 12.1 Reloading the system software is NO solution It is no solution to this problem to completely reload the system and application software in the hope that, after this reload, the bad blocks won't appear at the same points in the software as they did before. While this might be true, all that would be accomplished by this process would be to move the problem to some other place in some other software module in the system (while retaining it on the same place on the hard disk). This might work for the particular bad block in - 38 - question; but it also might not, and it might also reveal other bad blocks elsewhere causing twice as many problems, problems that perhaps won't even appear until some time in the future. 12.2 Hard disk surface checking as one solution As was mentioned above, the diagnostic floppy has a hard disk surface-testing function which is supposed to detect bad spots, place them on the bad block table of the hard disk, and give blocks belonging to those spots alternate tracks and sectors so they are never referenced again at those spots by your system. If you wish to go through the agonizing process of backing up an entire hard disk, reinitializing it, doing the extremely time-consuming surface test, and then reloading all software and data, this surface-testing function, used in this manner, might, temporarily, solve your problem (though it might not -- not even temporarily -- as mentioned above, and it might lose more good blocks of your hard disk). Also, there is a so-called "non-destructive" surface- test of the diagnostic floppy that can be run without the necessity of reinitializing your hard disk. This option has the additional problem of potentially being destructive of hard disk data. Specifically, after putting the number of any bad block it finds on the bad block table and giving it an alternate track and sector, this program loses that data! If the bad block it detected had crucial data on it, it will now be lost forever! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . If you would like to find out more, please contact David at the address listed below. I have not seen or tried any of his software. David Solan Objective Programming Incorporated Post Office Box 123 Norwalk, CT 06856 ATTMAIL: !dsolan VOICE: (203) 866-6900 -- :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: {codas,u1100a}-----\ Mark Hilliard rutgers!rochester!pcid!kodak!gizzmo!mark N2HHR {lazlo,ethos,fthood}-----/