"Peter J. Braam" wrote:
>
>> As for the copying taking an hour:
>>  I get a bandwidth of at least 250kb/s when running both the client
>>  and server on a 486/66 with 16MB RAM and 30MB swap. Which results in
>>  _copying_ a clean linux-2.1.85 kernel tree in around 3 minutes.
> 
> What do you mean with _copying_?  I think what we are interested in
> here is tar zxvf linux-2.1.84.tar.gz.  This is slow, but should not
> take an hour. 

Only in the sense of not compiling, that would produce less traffic, and
therefore stress coda a lot less.

> BTW, neat, I didn't know this.  Jan you could try (with a large cache):

Not just a bit larger, normally I have a 10MB cache. Untarring the linux
kernel will require:

uncompressed kernel src = 43 MB -> 45-50MB cache
nr. of files/dirs       = 3994  -> 12000 CML's

  FUN!

> cfs wd  (write disconnect)
> tar zxvf linux-...tar.gz
> cfs checkservers
>
> and time that!  This is similar to the way the write back caching will do
> the work. 

I'll do that.

Are you interested in the local client-server situation, or the serial
connected client-server? Or both?

I should add that under normal circumstances venus will jump into
write-disconnected mode very quickly (sometimes even locally). In this
mode I had problems that the CML was overflowing (small cache). To solve
this, I force a write-reconnect immediately after a weak-connection is
detected. This starts integrating the changes, and seems to slow down or
block the process that creates all the new files, the operation takes
longer, but does finish successfully.

Shouldn't the last operation be `cfs wr' (write reconnect)?

> - Peter - 

Jan