Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!ucsd!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!umich!terminator!pisa.ifs.umich.edu!rees
From: rees@pisa.ifs.umich.edu (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Can anyone help with a salvol problem?
Message-ID: <1990Aug31.124334@pisa.ifs.umich.edu>
Date: 31 Aug 90 16:53:43 GMT
References: <1990Aug30.152435.23881@watdragon.waterloo.edu> <4c83a20b.20b6d@apollo.HP.COM>
Sender: usenet@terminator.cc.umich.edu (usenet news)
Reply-To: rees@citi.umich.edu (Jim Rees)
Organization: University of Michigan IFS Project
Lines: 34

In article <4c83a20b.20b6d@apollo.HP.COM>, ced@apollo.HP.COM (Carl Davidson) writes:
  It appears that the electrical storm caused the drive to scribble random
  garbage over the surface of the drive media. Salvol, when attempting to 
  repair the disk, sees this scribbling as bad formatting (chk_hdr is, I assume, 
  the internal salvol routine that validates the disk block header) and flags
  the blocks to be replaced. Unfortunately, in the second pass salvol runs out
  of space to store the bad blocks in and so can't complete its job. It's just as
  well, really, because it's unlikely that the disk media is actually bad here
  and you don't really want to throw all those bnlocks away unnecessarily.

I don't think that's quite true.  Bad block headers don't imply bad media.
Salvol should be able to fix these, but sr10.2 salvol doesn't have enough
internal table space to remember them all for pass 2.  sr10.3 salvol should
fix this.

  There really isn't much you can do with this output except go on and invol 
  the disk. Any repairs attempted by hand would be difficult at best. It's better
  to let invol straighten things out itself.

Fixvol can fix bad block headers, but it's a bit tedious.

Each disk block contains three sets of data.  The first is the format data,
which is used by the drive to find the right sector.  If this is bad, you
need to reformat the sector (fixvol can do this on a track by track basis).
The second set of data is the block header.  This is used by Domain/OS to
store the uid and logical block number of the file the data goes with.  Most
normal operating systems don't have this.  I first came across it in the
Alto operating system, where it was used successfully to recover the disk if
the inodes (vtoc) got corrupted.  Domain/OS uses it somewhat less
successfully.  In fact, it seems to cause more trouble than it's worth.  I'm
not even sure salvol ever uses it to reconstruct a corrupted vtoc.  It also
makes it difficult to build a disk controller for Domain/OS, since the
blocks are non-standard size (not a power of two) and ideally should be
transferred into memory in two pieces.