Bradley,

Congratulations that's great.  

1. The memory size of venus is proportional to the cache size.  (The file
/usr/coda/DATA is mmapped.)  We plan to reduce the VM size somewhat by
mapping that file as copy on write rather than anonymous. 

Although the size is large, only the part of DATA that you are actively
using will be kept in RAM the rest will be swapped out and just sits
there.  DATA contains the directory info and file attributes, the ACL's
the hoard database and that sort of thing. 

2. CVS is a real Coda stress tester at the moment, and for example, I
think that checking in doesn't work right now because we have no lock
support. I'll probably hack that in soon though.  I am not surprised that
you see some strange errors, I do too here.

Running a client on a server is possible but quite slow.  I think that you
will see a LOT of swapping, since the server has a big footprint too.  I
wouldn't recommend using it on the server.

Good luck. We'll continue to try to make Coda more useable.

Peter 




On Thu, 9 Oct 1997, Bradley C. Kuszmaul wrote:

> I seem to have solved my previous problems setting up my coda server.
> (I uninstalled everything, did a brainwipe on the /vicepa partition,
> deleted /usr/coda, and started over from scratch.   The second time
> things went better.)
> 
> I have a few questions:
>  (1) venus, running on my laptop, is chewing up 20megabytes of virtual
>      memory.   (I think I gave it an 80MB cache.)  The laptop is
>      connected via modem to the server.  Is there something
>      I should be doing differently to keep the VM size down?
>  (2) My other machine is the fileserver.    It has a venus running on
>      it so that I can see /coda.   I have seen strange things there:
>      The performance is quite low, and I got some strange errors when
>      I tried to create a cvs sandbox in my coda partition.   Should I
>      not be using venus on my fileserver?  (I haven't yet tried venus on
>      another machine on the same LAN.)
> 
> -Bradley
> 
> 
>    
>