Coda File System

Re: Problem on starting coda after unsyncro

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 30 Nov 2001 13:24:03 -0500
On Thu, Nov 29, 2001 at 11:00:17AM +0100, Andrea Cerrito wrote:
> So I tried to restart venus on both cluster node: on cluster A were
> no problems, but on cluster B I found this on console log (and venus
> never mounted /coda).
> 
> 10:53:05        6369 cache files on free-list
> Assertion failed: vol->IsReplicated(), file "fso1.cc", line 1889
> Sleeping forever.  You may use gdb to attach to process 4613.
> 
> My problem is:
> 
> - - why venus can't mount /coda?

Because during the startup venus tried to do a CML optimization on an
object that logically can't have a CML because it is in a non-replicated
volume. This seems to be an artifact of the local-global repair code
that is 'temporarily' moving object to a fake non-replicated volume to
avoid conflicts with the global replica. However it doesn't always clean
up nicely after itself when no repair is done, or when repair fails.

> - - how can I force /coda to be mounted to retrieve data? I'm sure
> there are data into client cache, and I must retrieve it.

I do not know of a way to nicely recover from this. It pretty much
requires a client reinitialization, but you should still be able to
recover any write-disconnected modifications ('lost' files) from
/usr/coda/spool/<userid>/<volume>.tar (or /var/lib/coda/spool on Debian)

Jan
Received on 2001-11-30 13:24:59