[2205] in SIPB-AFS-requests
Re: AFS server discoveries, client bugs
daemon@ATHENA.MIT.EDU (Tom Yu)
Wed Jan 3 06:06:30 1996
Date: Wed, 3 Jan 1996 06:06:16 -0500
To: ghudson@MIT.EDU
Cc: sipb-afsreq@MIT.EDU, netbsd-afs@MIT.EDU
In-Reply-To: <199601031035.FAA03238@lola-granola.MIT.EDU> (message from Greg Hudson on Wed, 3 Jan 1996 05:35:49 -0500)
From: Tom Yu <tlyu@MIT.EDU>
(removed linux-dev from the cc line... they probably don't need to
hear more of this)
Further investigation revealed that bulk moves that I had previously
done (locallly from one of the servers) were not affected by this bug
because /usr/afs/bin/vos is the 3.2 version and it happens to be
before /bin/athena/vos (probably 3.3 or 3.3a) in root's path. This
meant that the lossage did not occur. I checked the soruces in afsdev
and found that the bug appears to have been introduced along with the
explicit cleanup code in the 3.3 vos.
>From: Greg Hudson <ghudson@MIT.EDU>
>
>There is still a turd on ronald-ann2:/vicepg, and I think the volume
>header will have to be deleted from /vicepg by hand (salvages have not
>removed it).
From looking at the logs, it seems that no one has forced a salvage
since the machine booted. Maybe if a salvage is forced on that
partition the bogus volume will go away. I have seen this behavior
before, but am not certain what causes it. I do not believe that
removing the volume header by hand is the right answer, since the
salvager will simply recreate it when it gets to that volume.
---Tom
