From: glyn@cs.UAlberta.CA (Reade Glyn Devin)
Subject: help -- problems with hard drive
Organization: University of Alberta, Edmonton, Canada
Date: Wed, 30 Dec 1992 20:16:22 GMT

Hi folks.

I've got a problem with my hard drive that I haven't been able to
track down, and I would appreciate any suggestions.  I'm using a 40 Meg
AE Vulcan Gold upgrade, ZipGS 9/32, Prosel 16 with error recovery and 
disk verification on backup.  There are (normally) two partitions, the
first one being 25024.0k.  Memory is a Ramkeeper with 3Meg GSRam+ and
500k apple card.  Other cards are normally used, but were removed for
trouble-shooting.  Here's the story:

The problem first came up while trying to do a complete-mode
optimization of my first partition using ProSel.16.  The error was
a block reference error.

I did a restoration from backup (I keep a series of three backups
for each partition, used in succession).  I encountered an error $27
(I/O error) on the restoration.

By the way, I always do a directory repair & bad block lockout (Prosel
volume repair) before any restorations from backup.

I tried again starting with a low level format by typing 'AE' at the
main menu in Partition Manager (Vulcan Gold version).  It reported the
bad tracks of $15.0  $1A.2  $1B.2  $1C.2

In addition to the (three) bad blocks reported by Prosel (2762, 2773,
5955), I also locked out the blocks mentioned in the paragraph above.
I think I translated them correctly as:
	2267, 2268
	2888, 2889
	2996, 2997
	3104, 3105
I included two blocks each to account for a possible off-by-one error.

I no longer got error $27 on restoration, but every time I try a complete-
mode optimization I get 'Block Reference Error, Reference Address $0CCD'
I've tried this multiple times with different backup sets.  I have tried
locking out any index blocks used by the file (and its parent directories)
being optimized at *crash* time.  The same error (Reference Address $0CCD)
always occurs even though different blocks are being optimized at the 
crash time.  $0CCD is also locked out.  There are no problems when I
do an optimiztion in Turbo-mode (turbo-mode does not optimize directories
or index blocks, just data blocks).

I thought that maybe I had a bad set of initial blocks on my partition
(blocks 0-5 and the bit-map), so I tried making a small '/BAD' partition
with my normal partitions following.  Only when /BAD is 1.5Meg or larger
do the problems disappear.  When the size of /BAD is changed, the blocks
assigned to BAD.BLOCKS are recalulated with the offset.  When resizing
/BAD, I was careful not to get any known bad blocks in the first $12 blocks
of the partition.

An interesting thought is that regardless of the size of /BAD, the error
is _always_ "Reference Address $0CCD".  If $0CCD was a bad block, you
would expect the reference to change with the size of /BAD.  Since index
files store addresses with the (reversed) high and low bits offset by
$100, I don't have a utility which can tell me which blocks make
reference to $0CCD (remember that since $0CCD is locked out, Prosel
Info Desk will report it as part of BAD.BLOCKS).

I lock out blocks out by using Prosel 16 Zap Block Editor (Block Warden),
modifying the BAD.BLOCKS file (only file on disk at the time) then using
directory repair to fix the volume bit-map.

I've verified that all software in use (Prosel, Partition Manager) match,
byte-for-byte, with the original disks.

There is no possibility of virus-infected software being involved at
this stage, unless it can hide itself in the BRAM (which I seriously
doubt).

I checked my ROM disk (now being used as a boot volume) and RAM using
the Ramkeeper CDA.  MemoryTest.CL reports no errors on RAM.  There is
no RAM disk.

As you can see, I'm grasping at straws.  Any help appreciated.

--Devin		glyn@cs.ualberta.ca