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:[EMAIL PROTECTED]]
> Sent: Tuesday, August 03, 1999 9:14 AM
> To: [EMAIL PROTECTED]
> 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
>
