Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ME.UTORONTO.CA!sun
From: sun@ME.UTORONTO.CA (Andy Sun)
Newsgroups: comp.sys.mips
Subject: Re: bad block tables lost?
Message-ID: <91May15.232155edt.20146@me.utoronto.ca>
Date: 16 May 91 03:21:42 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 58

Newsgroups: comp.sys.mips
Subject: Re: bad block tables lost?
References: <1991May15.010630.24949@murdoch.acc.Virginia.EDU>
Organization: U of Toronto, Dept. of Mechanical Engineering

wrp@biochsn.acc.Virginia.EDU (William R. Pearson) writes:

>	The 300 Mbyte system drive on my MIPS M/120 died today - there
>seemed to be a bad sector in the swap partition (fortunately I have a
>service contract and should get a new one tomorrow).  What surprised
>me was my inability to recover from the problem by reformatting the
>disk and scanning for bad blocks.  When I reformatted with the format.std
>program from 4.52 distribution tape, no problems were encountered.
>Scanning likewise did not uncover any bad blocks.  When I listed the bad
>blocks, none were found.

I found this on 4.51 last week. Don't know that this still doesn't get
fixed in 4.52. I worked on an M/1000 that has lost its original defect
list (i.e. bad sector table). The documentation said the scanning phase
of format.std will pick out the bad sectors, but apparently it didn't,
not all of them anyways (it got 15 out of 212). Everytime I installed the
OS back, I got this "sector not found" error and I haven't a clue what's
going on. Finally, after entering the manufacturer's defect list + the
disk scanning, this problem finally disappeared. I don't see any point
in this so-called "scanning" phase, especially it is a time-consuming
process and it's actually going through each cylinder.

>	I was surprised when my customer support person told me that I
>should not have tried to list the bad block table, because, according to
>him, a bug in the software causes the table to be erased after it is
>listed, and it must be reentered manually.  Is this true?  Is this fact
>mentioned somewhere in the volumes of release notes that I am constantly
>refered to?  Is there any version of RISC/os that allows one to format a
>disk and examine/edit the bad-block table without destroying it?

It seems to work under RISC/os 4.51. That is, add/delete/list without
destroying the bad sector table. I performed a scan first and then add
the manufacturer's defect list and list the content before writing to
the volume header and it didn't get destroyed. The disk that I worked
with is a Fujitsu 2372K and the controller is an Interphase SMD controller.

>	This seems like a very serious bug to me. It is also insidious,
>since it tends to require that I keep my machine under maintenance
>with MIPS, since it is now very difficult to reformat a disk with a
>few bad blocks; the disk almost must be returned to the factory and
>exchanged for a known good one.  On other computers, I have found that
>disks may loose a sector now and then, often because of bad power
>fluctuations, but they can then be reformatted, scanned, and put back
>in use in an hour or so. By not allowing the bad-block table to be
>examined and modified, a simple reformat becomes a disk exchange.

>	Earlier, I installed a third-party disk after formatting without
>any problems under RISC/os 4.01(2?).  Did its format/scan/list-bad-blocks
>function better?

>Bill Pearson

Andy