Coda File System

Re: Problems with tar archives

From: Matthias Teege <>
Date: Thu, 11 Oct 2001 18:19:37 +0200
On Thu, Oct 11, 2001 at 10:44:28AM -0400, Jan Harkes wrote:
> On Thu, Oct 11, 2001 at 09:39:08AM +0200, Matthias Teege wrote:
> > I'll append the last 100 lines from venus.log. There you can see that all
> > directorys under /coda has gone.
> ?? I don't see anything being gone. The few ENOENT errors look like
> stat operations to check whether the destination of a rename really
> doesn't exist. I also see that you're running write-disconnected, and

Hmm, the write-disconnected I see to but it wasn't my intention. Both
servers are connected with a fast network and I don't want to use the
disconnected mode between these servers. How can I turn this mode off.
Cfs wr isn't the right one? Or is this because the cvsup is faster tha
coda can write the files over the network?

> have been in that mode for a while because venus is using temporary
> fids. There temporary fids will be replaced by global fids right before
> reintegration, perhaps the kernel module didn't get the right purges and
> will be using the wrong identifiers once a chunk gets reintegrated.

Is this a config problem or an bug? Sometimes I get:

Oct 11 17:45:23 gie /kernel: coda_call: tsleep returns -1, cnt 125
Oct 11 17:45:23 gie /kernel: coda_call: tsleep returns -1, cnt 126
Oct 11 17:45:23 gie /kernel: coda_call: tsleep returns -1, cnt 127
Oct 11 17:45:23 gie /kernel: coda_call: tsleep returns -1, cnt 128

from my kernel.

> > Can It be an cache problem? I have two servers and in this case venus run
> > on server 1 (scm) and the volume to write is on server 2. All files must
> > write over network to server 2. So I setup a big cache (300000) on server
> I would expect that a cvsup in (write-)disconnected mode would require
> more than 300MB.

Probably not,
du -shk ports
99M    ports

but a lot of small files.

Many thanks

Matthias Teege -- --
make world not war
PGP-Key auf Anfrage
Received on 2001-10-11 12:20:39