(Illustration by Gaich Muramatsu)
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. JanReceived on 2001-10-09 12:47:43