On Tue, Oct 09, 2001 at 07:32:48PM +0900, Stephen J. Turnbull wrote:
> I'm consistently getting a crash (assert at rvmlib.c l.209) as soon as
> a client tries to update the server.  Any suggestions?  (I'm using
> files for the RVM DATA and LOG, and yes, there's plenty of free space
> on the partition.)  I've tried rebuilding from scratch, with CVS
> updated today.  Same results.

This could be the resolution log that hits it's administrative limits.

Every replicated volume keeps a log of recent modifications which is
used during server-server resolution. This log is normally truncated by
successful COP2 messages, a message indicating that all server have seen
the update. Or by successfull resolution, i.e. the client noticed a
discrepancy between server responses, triggered resolution and the
servers are now back in sync.

Now with singly replicated volumes, things are a bit different. We'll
still see COP2's, but the client will never see differences between
servers, so it will never trigger resolution. And COP2 messages might
get lost, or in the case of reintegration aren't really consistently
covering every change, which means that singly replicated volumes slowly
build up a resolution log that will never get truncated.

I've tried to disable resolution on newly created volumes by default,
but used a variable that I 'thought' contained the volumeid. However it
didn't.

It might be smart to first grow the log a bit to create a buffer if I
forgot to block any logging in some obscure code paths. And then we turn
off the resolution log which should stop the server from adding anything
else.

    volutil -h <server> setlogparms <volumeid> reson 4 logsize 8192
    volutil -h <server> setlogparms <volumeid> reson 0

> 18:08:18 Entering GrowVnodes for volid 1000011, vclass 1
> 18:08:18 GrowVnodes: growing Small list from 23808 to 24064 for volume 0x1000011

On the other hand, perhaps there isn't enough RVM available on the
server, and you really need to increase the RVM size.

The tool here is 'norton-reinit', which can dump the essential metadata
structures of a server. I used it a couple of months ago when one of our
production servers had no allocatable RVM left. It goes a little
something like this,

    norton-reinit -rvm <rvmlog> <rvmdata> <rvmdatalength> -dump \
	ServerDump skip <volumeid> <volumeid>...

Then the best thing would be to backup the old rvm log and data
somewhere. I've had to go back to tape once when the dump was corrupt
and the old rvm got wiped by the following step.

    vice-setup-rvm

    norton-reinit -rvm <rvmlog> <rvmdata> <newrvmdatalength> -load \
	ServerDump skip <volumeid> <volumeid>...

The 'skip' volumes are useful if there are any volumes that give
problems.

Jan