Directory data on the clients contributes too:
  2048 minimal per directory for which data is available in Venus, 
       more for larger directories.

- Peter -

> -----Original Message-----
> From: Jan Harkes [mailto:jaharkes_at_cs.cmu.edu]
> Sent: Tuesday, August 03, 1999 9:14 AM
> To: codalist_at_TELEMANN.CODA.CS.CMU.EDU
> Subject: Re: newbie questions on sizes...
> 
> 
> On Tue, Aug 03, 1999 at 12:58:29AM -0600, Lou Langholtz wrote:
> > Hoping someone could easily answer some newbie questions for me:
> > 
> >   1. The docs seem to encourage using caches of only 600MB or less. Is
> >      that just because it takes a while to prep a new cache or is there
> >      some technical problem using a cache a full 2GB large?
> 
> The main constraint is RVM usage. Venus will allocate around 10% of the
> cache size in RVM, to store the required meta-data. And RVM is copied
> into memory, so with a 2GB cache Venus will load about 200MB into
> memory. Thus it takes a longer to start Venus when the available
> physical memory is less and we need to swap to disk.
> 
> The amount of needed RVM is actually calculated from the following
> formula. (I'll actually dig into this a bit extensively as I hadn't
> done the calculations for a while, but they are useful to know):
> 
>  modification log entries * ( CML entry size(228) + 64 ) +
>  cachefiles               * ( FS object size(412) + 64 ) +
>  cachefiles / 4           * ( directory data size(28) + 3072 ) +
>  cachefiles / 64          * ( volume entry size(456) ) +
>  cachefiles / 256         * ( volume storage group entry size(52) ) +
>  hoard entries            * ( HDB entry size(32) + 128 ) +
>  128 * 1024
> 
> Where "modification log entries" defaults to CacheBlocks / 6,
>       "cachefiles" defaults to CacheBlocks / 24, and
>       "hoard entries" is CacheBlocks / 48.
> 
> So if you don't override the defaults, using a 2GB cache you end up with
> enough metadata to store:
> 
>                            size         Command line option
> 349525 mles                97.3MB	(-mles)
> 87381 cachefiles			(-cf)
>  87381 fileobjects  39.7MB
>  21845 directories  64.6MB
>  1365 volumes        0.6MB
>  341 servergroups    0.1MB
>                           105.0MB
> 42690 hoard entries         6.7MB	(-hdbes)
> 128KB extra space           0.2MB
> 		          -------
>                           209.2MB
> 
> The mles, fsos, and hdbes are actually allocated during initialization,
> so there is not much sharing of rvm space. But you can easily reduce RVM
> usage a lot by reducing f.i the high number of CML entries. A good guess
> is about 3-6 times the number of files you are likely to modify while
> disconnected. For example, a disconnected build of the Coda sources
> creates/modifies about 1303 files and generates 3122 CML entries. 
> 
> >   2. Does coda have support for bigger than 2GB cache sizes?
> 
> I don't know, haven't tried. As the cache-usage is counted in 1KB blocks
> instead of bytes it could actually work out of the box.
> 
> >   3. If coda supports bigger than 2GB caches, is the largest file size
> >      always the size of the cache or is it limited to 32bits large or
> >      something? Ie. is coda a 32 bit file system?
> 
> Yes, Coda is still very 32-bit oriented. Even on a 64-bit processor,
> like the sparc64 we have to compile and run 32-bit object code.
> 
> Jan
>