Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cprice
From: cprice@mips.com (Charlie Price)
Newsgroups: comp.sys.mips
Subject: Re: bad block tables lost?
Message-ID: <3585@spim.mips.COM>
Date: 16 May 91 21:16:46 GMT
References: <91May15.232155edt.20146@me.utoronto.ca>
Sender: news@mips.COM
Organization: MIPS Computer Systems, Inc
Lines: 68
Nntp-Posting-Host: lloyd.mips.com

In article <91May15.232155edt.20146@me.utoronto.ca> sun@ME.UTORONTO.CA (Andy Sun) writes:
>Newsgroups: comp.sys.mips
>Subject: Re: bad block tables lost?
>
>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.

The scan pass doesn't discover all the blocks on the manufacturer's
defect list.
It CAN'T.
This is definitely a pain in the nether regions,
but there is not much that we can do about it.
If any other vendor has a superior scheme for finding defects in
the field, I'm sure that MIPS would like to know about it.

I used to work for an IBM-compatible disk manufacturer 
developing test equipment (runing under UNIX!).
Discovering "defects" on a HDA (Head-Disk Assembly --
the part with disks and heads, but little electronics and no motor...)
was an involved process.
We built elaborate equipment with special electronics that did a
great deal more than the normal read/write operation and servo control.
One thing that we spent a lot of effort to detect was "marginal" areas
where the drive would read/write reliably if the head were exactly on
track, but where it could fail if it were very slightly off the center
of the track (but within servo parameters).
Another "marginal" manifestation is where the coating is "thin"
(not very many oxide particles) and sometimes write/read worked
and sometimes you lost a bit or two.

There is NO WAY a standard drive in the field equipped with
standard read/write and servo electronics controlled by a
standard (SMD or SCSI in this case) controller can duplicate
what a manufacturer can do.
The scan pass has no magic available.
For each sector on the drive, you write a data pattern that should
be a worst-case pattern for the media and data encoding scheme
(the maximum number of flux transitions) and then you read it back
and see if you get the same data or if the drive/controller gives you an error.
If the drive/controller gives you an error then you have a bad block,
otherwise it must be good, right?

You might observe that
there is something very time consuming that could be done with
standard electronics and controllers that the formatter scan
pass doesn't do today.
Right now it visit the blocks in order and ends up being reliably
on-track for most of them.  It could do a reasonably large seek
between each block (visiting them in some nonsequential order)
to introduce some servo noise and track-settling activity into the process.
This *might* increase the likelyhood of positioning the head-arm
in-spec from the servo track but slightly off-center and
thereby show up more marginal blocks.
This may be grasping at straws.
There is no way that you can reliably use the standard controller to
produce all the situations that the drive will see in use --
at least in a reasonable amount of time.
-- 
Charlie Price    cprice@mips.mips.com        (408) 720-1700
MIPS Computer Systems / 928 Arques Ave.  MS 1-03 / Sunnyvale, CA   94088-3650