Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!joelm@EDDIE.MIT.EDU@apollo.UUCP
From: joelm@EDDIE.MIT.EDU@apollo.UUCP (Joel Margolese)
Newsgroups: mod.computers.apollo
Subject: (none)
Message-ID: <8701061930.AA06331@EDDIE.MIT.EDU>
Date: Tue, 6-Jan-87 14:20:04 EST
Article-I.D.: EDDIE.8701061930.AA06331
Posted: Tue Jan  6 14:20:04 1987
Date-Received: Tue, 6-Jan-87 23:19:32 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 38
Approved: apollo@yale-comix.arpa

Newsgroups: mod.computers.apollo
Subject: Re: Bad block forwarding
Summary: 
Expires: 
References: <8701051707.AA01631@utah-cs.ARPA>
Sender: 
Reply-To: joelm@apollo.UUCP (Joel Margolese)
Followup-To: 
Distribution: 
Organization: Apollo Computer, Chelmsford, MA
Keywords: 

In article <8701051707.AA01631@utah-cs.ARPA> peterson@UTAH-CS.ARPA (John W Peterson) writes:
>Does anybody know how to go about adding bad blocks to an Aegis filesystem
>that's in use?  I tried the following procedure:
>          ...
>What I'm not sure about is if the numbers reported by lsyserr are the same
>ones used by invol.  Has anybody seem a documented procedure for doing this
>operation?

Your procedure was correct.  lsyserr (and disk_err) report physical daddrs, which
are daddrs relative to the beginning of the physical disk volume, as opposed to the 
any of the logical volumes that may be on the disk.  Running SALVOL after adding
badspots to the badspot list is very important to set the trouble flags and to insure
that noone else tries to use that block.
 
                                                                            

Joel Margolese          UUCP:  ...{attunix,uw-beaver,decvax!wanginst}!apollo!joelm
Apollo Computer         ARPA:  apollo!joelm@mit-eddie.arpa

                        





-------