Resizing RVM memory

Ok, resizing a servers RVM data segment, this is pretty hairy stuff, and really only should be considered if there is no other way out and you definitely, 100% surely, undoubtedly know that the problem is caused by the server running out of RVM data.

Other causes for server problems can be,

Resolution log wraparound, caused by prolonged disconnection from another server in a VSG (or a misconfigured client/firewall so that the client isn't talking to the other server in the VSG).
RVM log exhausted. The current RVM allocator, RDS, only tries to defragment memory when an allocation fails. The transaction that results from the allocation is huge. Theoretically it could be about as big as the RVM data size, which ofcourse defeats the whole idea of having a small and fast log. The RDS allocator should be changed to do more agressive coalescing when data is freed so that we avoid these huge transactions. agressive coalescing is used in recent versions of RVM
Zillions of other reasons.

How to know we ran out of RVM data and not any of the zillion other reasons? Check the server logs, once in a while any server will dump out statistics amongst which you can find something like,

14:39:51 Printing RDS statistics

Number of
 Free bytes:     2c05900
 Alloced bytes:  43fa3a0

The numbers are hexadecimal, but obviously when Free bytes has become a really small number, the server probably doesn't have any RVM memory left. volutil printstats forces these statistics to the log if you can't find them/the server crashes before it prints them.

Ok, now on with the real stuff.

First, check whether there are any backup volumes. There probably aren't any, as you've been using tar for backups instead of volutil backup/volutil dump, but you never know. So with the server up and running, we can do something like,
```
$ volutil getvolumelist | grep ^B | \
            sed 's/^B$.*$ I$.*$ H.*/volutil purge \2 \1'
>
purge-backups
```
The file 'purge-backups' should then contain lines like,
```
volutil purge d10000ad vm:u.ecc.0.backup
volutil purge d10000ae vm:u.gkesden.0.backup
volutil purge d10000af vm:u.jaharkes.mail.0.backup
volutil purge d10000b0 vm:u.jclopez.0.backup
volutil purge d10000b1 vm:u.jflinn.0.backup
```
Now we can purge these volumes by running
```
$ sh -x purge-backups
```
If the server is unable to stay up and running long enough, you can continue but it will take somewhat more effort to reload RVM as we have to skip these backup volumes during recovery. During the following server startup all the linkcounts on containerfiles will be off by one and it will complain a lot, but it did work the last time I tried it.
Next step, we can shut down the server and dump the contents of RVM with norton-reinit.
```
$ norton-reinit -rvm
<
rvm-log-device/file
>
<
rvm-data-device/file
>
\
<
rvm-data-length
>
-dump rvmcontentsdump
```
This should give us a file rvmcontentsdump that contains all we need to reconstruct the server state in a newly initialized RVM area.
Now we have to create a new bigger rvm segment where we then can restore the data to. However I had the restore step go wrong a couple of times, so it's best to first try a recovery/server startup with a 'temporary' RVM setup in a file before overwriting existing log and data partitions. (ps. you should probably use absolute paths wherever I say new_rvmlogfile or new_rvmdatafile )
```
$ rvmutl
* i new_rvm_logfile 5M
* q
$ rdsinit -f new_rvmlogfile new_rvmdatafile 209715200 0x50000000 \
    0xb000000 0x100000 80 32
```
The rdsinit parameters are for a 200MB rvm data segment, I took the numbers from the vice-setup-rvm script.
Restore rvm into the new log and data files.
```
$ norton-reinit -rvm new_rvmlogfile new_rvmdatafile 209715200 \
    -load rvmcontentsdump
```
If there are any volumes that give problems, it is possible to add skip < volumeid > to the commandline. But you'll have to do the rvmutl/rdsinit steps again each time you retry norton-reinit.
Configure the server to use the new log/data files by appending the following lines to the end of /etc/coda/server.conf ,
```
rvm_log="new_rvmlogfile"
rvm_data="new_rvmdatafile"
rvm_data_length=209715200
```
The last definition in the configuration file is the one that is used, so you shouldn't have to worry about previous definitions higher up in the file. Alternatively, if you're a long time Coda user, you might still be using the /vice/srv.conf setup. In this case, backup the old file and create a new file containing a single line,
```
-rvm new_rvmlogfile new_rvmdatafile 209715200
```
Smoke test! we start the server and see if it makes it all the way to 'Fileserver started'. If it did the reinitialization worked. If you want to keep using the new log and data files, everything is done now, if you want to re-use previously used partitions 'kill -9' the server and go back to where we were reinitializing the RVM log and data files using rvmutl and rdsinit.

This is Coda server brainsurgery at its best (or worst).

Jan

Coda File System

Resizing RVM memory