(Illustration by Gaich Muramatsu)
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 -- Matthias Teege -- matthias@mteege.de -- http://emugs.de make world not war PGP-Key auf AnfrageReceived on 2001-10-11 12:20:39