Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!apollo!ced
From: ced@apollo.HP.COM (Carl Davidson)
Newsgroups: comp.sys.apollo
Subject: Re: Can anyone help with a salvol problem?
Message-ID: <4c96ddb2.20b6d@apollo.HP.COM>
Date: 3 Sep 90 15:39:00 GMT
References: <1990Aug31.124334@pisa.ifs.umich.edu>
Sender: root@apollo.HP.COM
Lines: 69

From article <1990Aug31.124334@pisa.ifs.umich.edu>, by rees@pisa.ifs.umich.edu (Jim Rees):
> 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... 
>   ... it's unlikely that the disk media is actually bad here
>   and you don't really want to throw all those blocks 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.
> 

Sorry. I didn't mean to imply that bad block headers always meant bad disk 
media. It is often true, however, that the first indication of bad media 
is a high rate of disk block header errors in the system error log. In any 
case, Jim, you are correct that the sr10.3 salvol is better at handling this
situation. The patch tape contains a fixed salvol for sr10.2 that is capable
of handling this kind of corruption. 

>
>   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 stand by my statement that for this user, given that he already has his files
saved to other media and he doesn't have the improved version of salvol
readily available and he probably needs the disk storage that the damaged
volume represents otherwise he never would have spent the money to purchase
it, the best course of action is to simply invol the damaged volume and 
restore his files to it. Waiting for a patched salvol to arrive would 
probably take much longer and using fixvol is not a good idea.

Characterizing the use of fixvol to repair bad block headers as 
"a bit tedious" is the understatement of the century. The author of fixvol
thought the program dangerous enough in the hands of the uninitiated to 
have it print the following warning:

   Warning: this program is intended only for the use of Apollo service
   representatives.  Misuse of this program may irreparably damage your
   disk.  To exit, type "q" to the following prompt.

I cannot think of a case where I would recommend that a customer attempt to
repair a disk using fixvol. As Jim points out above, the Domain/OS disk 
structures are different from those of most operating systems and require
that someone using fixvol be knowledgeable of the internals of the file 
system. Please use the standard utilities to handle disk problems and leave
fixvol and its kin to folks like Jim who used to work in Apollo R&D and have
more than a passing acquaintance with Domain/OS internals.

Regards,
Carl

Carl Davidson  (508) 256-6600 x4361    | In the High and Far-Off Time, the
The Apollo Systems Divison of          | Elephant, Oh Best Beloved, had no
The Hewlett-Packard Company            | trunk.
DOMAIN: ced@apollo.HP.COM              |  -- Rudyard Kipling, Just So Stories