Coda File System

Re: okay, what am I doing wrong?

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Fri, 10 Jan 2003 14:22:13 -0500
On Fri, Jan 10, 2003 at 10:27:56AM -0800, Rod Van Meter wrote:
> > We cannot twiddle active files and directories into dangling symlinks.
> > So if there is some process that has it's current working directory in
> > /coda/rdv/nokia, or is caching open file handles, Coda can't turn the
> > object into a conflict. Often 'lsof | grep /coda' will show what
> > processes are holding references to files in Coda.
> 
> Doesn't return anything in /coda (just the usual stuff in /usr/coda).

Strange, I don't know why the dangling symlink isn't showing. It could
be that the kernel is caching too much, you could try

    cfs er /coda/rdv/nokia
    ls /coda/rdv/nokia

The 'er' or 'endrepair' will trigger venus to send a downcall that
invalidates the cached state in the kernel for that directory.

In any case, this 'conflict' is possibly caused by the fact that
resolution is disabled for this volume. Because it is a directory
operation that failed and volumes that have resolution disabled have a
stricter than usual consistency test for the storeid of a directory.
I'm not sure how to create a good testcase, but reenabling resolution
for that volume with volutil setlogparms <volid> reson 4 will switch it
back to the weaker consistency test.

The problem with enabling resolution on singly replicated volumes is
that when the 2nd phase of the 2 phase commit (the COP2 message) is
omitted, the volume builds up a resolution log. This log is never
truncated because there will never be a server-server conflict to
resolve.

> I created this set of files (actually copied them from somewhere else)
> all at the same time, and the sync failed partway through.  So some of
> them are stored on the server and are visible on the desktop, but most
> of them are only on the laptop.  The CML accurately reflects the set of
> files that have not been pushed to the server yet.

If 'cfs er' makes the dangling symlink visible, you should be able to
use repair. The client won't reintegrate until the repair has at least
forced the conflicting operations through (preserveall), or discarded
them (discardlocal).

If you can't get the symlink to show up, 'cfs purgeml /coda/rdv/nokia'
will discard the CML and allow you to get back to Connected mode.
Ofcourse all of the queued up changes will be lost, so you might want to
make a backup copy of the checkpointed tarball before purging the CML.

Jan
Received on 2003-01-10 14:23:47