Xref: utzoo comp.sys.att:7169 unix-pc.general:3456
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rutgers!dptg!mtunb!jcm
From: jcm@mtunb.ATT.COM (was-John McMillan)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: 3B1 Hard Disk Woes (Plea for HELP!)
Keywords: disk failure,diagnostics
Message-ID: <1583@mtunb.ATT.COM>
Date: 2 Aug 89 21:41:01 GMT
References: <8569@cbnews.ATT.COM> <1989Jul26.174524.21833@eci386.uucp> <850@flatline.UUCP> <580@uncle.UUCP>
Reply-To: jcm@mtunb.UUCP (was-John McMillan)
Distribution: na
Organization: AT&T ISL Middletown NJ USA
Lines: 74

In article <580@uncle.UUCP> jbm@uncle.UUCP (John B. Milton) writes:
:
> ...		 If so, it reads the existing BBT, formats the disk,
>then re-writes the old BBT when the format is complete. The reason is obvious:
>once a bad spot, always a bad spot. I, like most people would not like to give
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>a bad spot a second chance. If you want to dump the old BBT, you have to trash
>the VHB to make the diag disk think it's a new, raw disk. The low level format
>re-writes the ENTIRE track from index to index, gaps, headers, data, everything.

Be more charitable, John:
	Redemption IS possible, for some... but it takes love and attention.

Brother McMillan has spent long nights with several disks, and twice
the WORD has driven satan outta that disk!

We've been here before... o yes, children, this HAS BEEN SAID BEFORE!

Formatting a disk puts META information on the disk: it's like
	spraying the lines in the parking lot.  Without these lines,
	the disk cannot identify where the data is to be placed/grabbed.
	Each disk sector has a leading-edge gap, mark, identifier,
	gap/mark, user data, and final gap (sometimes w/ CRC).
	(OK -- I'm faking it, I haven't looked at the code for years!-)

Reading/Writing requires finding the sector identifier and precisely
	dribbling/sucking-up the data after hitting the internal mark.
	(Nice technical terms, eh?)

A bad block, then, is one which has:
		Proven itself to be unreadable, or unreliably readable.

Types of BAD BLOCKS:
     +	SOME blocks are simply a victim of poor penmenship:
		If a block is badly written, it may be unreadable.
	And bad vibrations -- not to mention bad karma -- or power
	glitches might cause bad writes.  (Likewise, some RETRIES may
	indicate NOT a bad block, but an Anomaly occuring during
	the READ cycle.)

     ++	If the write error is in the USER DATA field, the block may
	be recoverable by performing a FULL-BLOCK write: this will
	overlay the badly written bits without trying a read first.
	(If you write only 100 bytes, the other bytes have to be READ first.)

     ++	However, if the META information is corrupted -- by overwriting
	or by a marginal write during formatting -- only a re-format
	of that sector (track) can reclaim the block.

     +	OK: there are also MEDIA defects.  And THESE are the BAD BLOCKS
	which John was referring to, the ones we presume to be beyond
	salvation.

When my 67 MB drive began having MAJOR problems with bad blocks in the
SWAP -- I developed 120+ BAD BLOCKS  over two weeks, and some odd messages
from the diagnostics/surface check code -- I backed up everything.
	Feature -- this took only 3 days because CPIO was
	failing to verify dump after dump.

Then I ZERO'd the Bad block list, and reformatted.

And now, I have NO BAD BLOCKS.
And there's been not a single read error in the subsequent 4 weeks.

So I say, John: Bad Block lists aren't holy.  There are varying reasons
why Blocks are entered.  And good reasons for considering a reformat
-- 'though the manufacturers list of defects *MAY* be worth copying in.

john mcmillan -- att!mtunb!jcm -- speaking for hizzelf, only

PS: In a recent power hit in Lincroft, several 3B1 disks expired.
	Oddly, none of us with Spike/Noise suppression units were hurt.
	Then there's the fellah who hadn't put his suppression unit in
	service yet... sad fellah.  Don't you be sad: use line conditioning.