Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!ME.UTORONTO.CA!sun
From: sun@ME.UTORONTO.CA (Andy Sun)
Newsgroups: comp.sys.mips
Subject: Re: bad block tables lost?
Message-ID: <91May16.033557edt.18604@me.utoronto.ca>
Date: 16 May 91 07:35:42 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 55

Newsgroups: comp.sys.mips
Subject: Re: bad block tables lost?
References: <91May15.232155edt.20146@me.utoronto.ca> <1991May16.060214.22997@tkou02.enet.dec.com>
Organization: U of Toronto, Dept. of Mechanical Engineering

diamond@jit533.swstokyo.dec.com (Norman Diamond) writes:

>In article <91May15.232155edt.20146@me.utoronto.ca> sun@ME.UTORONTO.CA (Andy Sun) writes:

>Disks deteriorate over time.  The purpose of the scanning process is to
>find sectors that have become bad since the last time they were used.

Agreed. But if the software are smart "new" defects, it should recognise
"old" defects as well, because, afterall, they are all defects.

>Manufacturers have equipment to perform harsher tests than a normally
>operating disk drive can do, so they detect borderline blocks that would
>pass scanning tests.  This is why they provide an initial list in the
>first place.  It is generally considered better to avoid using a block
>that seems relatively likely to go bad within a few years, rather than
>use it until it goes bad (with loss of data).  So these are generally
>disabled even when scanning and usage would (temporarily) work.

The story I heard was nothing as magical as "detecting borderline blocks"
that "seems relatively likely to go bad within a few years". Defects
(bad sectors) on virgin disks are REAL defects. However, it is impractical
from a manufacturer's point of view to provide zero defect disks because
the cost will be much too high (to install better quality equipment as
well as better quality control). So they set a tolerance level (say, less
than 1% of the total disk capacity) to the product and supply a defect
list instead. Marking them as bad and avoiding them is cheaper than actually
getting rid of them. Disk manufacturers out there might want to confirm this.

>Nonetheless, if the scanning process passed a sector that produced
>"sector not found" a short time later, I'd say the scanning process is
>far from adequate.

Agreed. At first I thought the scanning just does read/write at random
locations only but I realized latter that it's actually going through
each individual cylinder during scanning. And that sounds pretty dumb
to me that it cannot detect major errors (errors that fsck.ffs will
recognise as errors and incapable of correcting). 

>(This does not represent the opinion of my employer or any other organization.)
>--
>Norman Diamond       diamond@tkov50.enet.dec.com
>If this were the company's opinion, I wouldn't be allowed to post it.
>Permission is granted to feel this signature, but not to look at it.

Andy

_______________________________________________________________________________
Andy Sun                            | Internet: sun@me.utoronto.ca
University of Toronto, Canada       | UUCP    : ...!utai!me!sun
Dept. of Mechanical Engineering     | BITNET  : sun@me.toronto.BITNET