Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!batcomputer!pyramid!voder!blia!ted
From: ted@blia.BLI.COM (Ted Marshall)
Newsgroups: comp.os.vms
Subject: Re: Repairing disks with corrupted index files
Message-ID: <3968@blia.BLI.COM>
Date: 22 Jan 88 18:43:49 GMT
References: <2471@trlsasb.oz> <880109071621.025@CitHex.Caltech.Edu> <613@acer.stl.stc.co.uk>
Organization: Britton Lee, Los Gatos, CA
Lines: 35

In article <613@acer.stl.stc.co.uk>, scott@stl.stc.co.uk (Mike Scott) writes:
> We've also had some nasty problems with a supereagle and QD32 controller (on a
> uVAX-II/VMS4.5). We were getting corrupted data without any warning apart from
> the disk write-locking itself. After reformatting the disk and restoring from a
> backup tape which had the corrupted disk data on it, there were a number of
> files apparently entered in two directories, one correctly, one wrongly.  The
> symptoms were consistent with the bad block replacement algorithm failing by
> revectoring a supposed bad block in the index file, then forgetting it had done
> this.  It makes me suspicious of the very idea of automatic bad block
> replacement, if this sort of thing happens with no warning: at least the old
> badblk.sys was pretty foolproof. 

I had a similar problem on a DEC RA-80 on a massbus controller on a 750.
I found that reading certain blocks yielded garbage with no warning except
that maybe 1 in 30 reads of that block would yield the correct data! Again,
all of this occured with no indication of errors from the driver!

One point on your seeing files in two directories. The backup of this disk
was made on a semi-live system (i.e. I was on, doing work that created files).
When that was restored to the new disk and the system brought up, I noticed
that while all of the directory entries for those files existed, several of
the files themselves didn't. In addition, some of the other directory entries
where linked to files that other people had created since the restore! It
appears that although all of the directory entries were caught in the backup,
some of the INDEXF.SYS entries weren't! Then since the directory entries
specified FIDs with last sequence number + 1, these new files also got the
same FID.

The bottom line is that the double-entry files you saw may not have had
anything to do with failures of bad-block replacement.

-- 
Ted Marshall       ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU
Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030     (408)378-7000
The opinions expressed above are those of the poster and not his employer.