Coda File System

Re: RVMLIB_ASSERT and RVM data sizes.

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Mon, 10 Jun 2002 11:30:21 -0400
On Thu, Jun 06, 2002 at 07:26:33PM +0100, Chris Shiels wrote:
> Firstly, thank-you for the very prompt reply to the email - much 
> appreciated.

This reply is a bit less prompt. My parents are in town, so I'm not at
CMU all the time ;)

> When we did our install we were lazy and went with the 5.3.19 RPM's - 
> will it be ok to just build and then deploy the /usr/sbin/codasrv
> binary and run this with the files from the 5.3.19 RPM's or are there
> additional files or issues that I need to consider?

That should work fine. I typically try to keep the servers compatible
as it simplifies life with testing. Setting up a new server everytime I
rebuild would become annoying at best. Clients are more likely to
require a reinitialization after upgrading as everything should normally
be on the servers and can be refetched.

> Also, a few things I'm not clear on:
> 
> We're currently running 30M(log)/500M(data) and I've found that I
> can't go to 30M(log)/1G(data), are there any other RVM data sizes that
> are available after the 500M one?  If so then how are the sizes
> calculated?

You can get pretty much any size you want. The RVM data is split between
two segments, a static area and a dynamic heap. The static area always
contains about 1MB, whatever the size of RVM. Then there is a little bit
of fixed overhead, a description of the size and where to load these 2
segments and the RVM header, about 3-4 pages (about 16KB) the rest is
used for the dynamic heap.

So all the parameters,

    rdsinit -f totalsize address heapsize staticsize nlists chunksize

    totalsize  - is how much on-disk data RVM should use.
    address    - is where RVM data is mapped into memory. Lower addresses
		 allow for a larger total size, but you might collide
		 with shared libraries. On Linux you can check with cat
		 /proc/<pid>/maps where the various shared libraries are
		 loaded. The binary itself is loaded at 0x08000000, and
		 shared libraries start around 0x40000000. The stack
		 growns down from 0xc0000000, and you definitely don't
		 want RVM to clobber the stack (or the other way
		 around). A static binary might be bigger, but doesn't
		 need the shared libraries, so the start address can be
		 lowered significantly.
    heapsize   - ~= totalsize - ( staticsize (1MB) + overhead (16KB) )
		 rounded to a multiple of 4KB
    staticsize - 0x100000 (1MB)
    nlists     - the allocator is using this many buckets to quickly
		 find free small memory chunks. first bucket contains
		 chunksize, the second 2*chunksize, 3*chunksize, etc.
		 someone once set this to 80, and that's the way it has
		 been. This should make the largest allocation list
		 about 2560 bytes.
    chunksize  - smallest allocatable piece of memory, must at least be
		 able to fit 2 pointers and 2 longs. So you'd need at
		 least 16 bytes, but 32 is a safe and good choice.

Jan
Received on 2002-06-10 11:37:02