> cfs wbauto /coda/marvin is going to hang, if I control+C it, the
> following is issued to dmesg:

The 'writeback' code isn't really useful, the idea was nice but it never
really worked out the way we hoped it would.

The basic idea was that we wanted to have client work write-disconnected
all the time, but have 'connected' mode semantics. This was achieved by
having client obtain a writeback permit as soon as they had CML entries
for a volume. The server would also preemptively break callbacks to all
other clients. Now if another client ended up being interested in a file
in the volume, the server would break the writeback permit and force a
reintegration before responding to the getattr or fetch.

The problem was that as a result of the callback, other clients would
often fairly quickly refetch the attributes due to a hoard walk or an ls
in a directory that contained the mountpoints of all user volumes. So a
write-disconnected client had to constantly reintegrate even if they
didn't have any relevant updates, and if they were connected over a slow
connection they would stall all other clients until the reintegration
completed.

Any case, I've decided to take most of the writeback related code out.

> coda_pioctl: Venus returns: -4 for (0x7f000000.0x1.0x1)

EINTR (i.e. ^C)

> coda_pioctl: Venus returns: -22 for (0x7f000000.0x1.0x1)

EINVAL

> Is there a list with all errorcodes? How can I get this client back into 
> 'normal' mode, what can I do to prevent these problems? What could be the 
> cause?

Most of the errorcodes really are the standard unix errornumbers.
I typically do a 'grep 22 /usr/include/asm/errno.h', except that on
recent glibc systems they've moved and split the errno.h file into
    /usr/include/asm-generic/errno-base.h and
    /usr/include/asm-generic/errno.h.

Then there are a couple of error numbers that are Coda specific. I
believe 198 is EINCONS /* inconsistent file */, 103 is VNOVOL /* volume
not found */ and a bunch of others. The problem with some error codes
like VNOVOL is that they also have an existing errno.h definition, in
this case it is ECONNABORTED, which can be a bit confusing sometimes.

In any case, I don't know why it isn't (yet) reintegrating. There are
some tests that check if the owner of the CML has valid tokens.
Sometimes a setuid application actually writes to files with a different
uid than you'd expect so you would need to get tokens for f.i. root or
some other local user.

Jan