On Wed, Jul 06, 2005 at 09:33:45AM -0500, mdbridge_at_verizon.net wrote:
>   I am looking into implementing Coda to provide server replication
>   and failover in a environment where an automated upload system
>   creates a directory for each file uploaded (In the case of graphics
>   files, two files per directory).  Based on the computations for RVM
>   space I am concerned that the RVM requirements for such an
>   arrangement could quickly become prohibitive.  Is RVM size still an
>   issue in later Coda implementations?  Also, would swapping of the

We have a tool that measures how much RVM a tree on a local file system
would use if it were stored in Coda. It is 'rvmsizer', not sure if there
is a link on the list to a prebuild binary somewhere, but it should be
in the coda-server rpm/deb packages.

That will give an accurate estimate of how much RVM would be used by a
representative sample tree, you can more easily extrapolate from those
numbers.

>   RVM to disk severely impact performance or does the meta-data
>   exhibit enough locality to keep performance acceptable?    Also,

RVM is treated as a single blob of memory, with a fairly simple
allocator which doesn't really take locality into account. Because of
the persistency of RVM we're actually more concerned about fragmentation
than locality.

>   could moving to a 64-bit architecture improve RVM performance?

I don't really think so, and rpc2 still thinks that an unsigned long is
a 32-bit value and the RPC2_Integers are used all over the place, you
probably wouldn't be able to run a 64-bit compiled Coda yet.

Jan