(Illustration by Gaich Muramatsu)
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. JanReceived on 1999-08-03 11:15:50