bad block recovery

[mark hilliard]

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}-----/