The sections contained here describe what vice-setup does for you. This information is useful for those who either wish to customize our default vice-setup script or wish to have a custom server setup outside the scope of Coda's setup script..
RVM initialization requires the selection of several parameters, each of which involve tradeoffs. Although the RVM log and data can be kept as regular UFS files, this is not recommended. Raw partitions have much stronger data consistency guarantees as well performance advantages. It is probably best to plan out the RVM partitions on paper first, taking into consideration both the effect on RVM performance as well as overall disk usage if you choose not to use the values provided in the vice-setup script.
The size of the log device is based on available space and issues involving truncation. Larger logs provide a longer accessible history of operations, are truncated less frequently, but each truncation will take a longer period of time. Shorter logs truncate more often, but each truncation takes less time. Log size is also strongly related to server startup time as well. We use a 90M log size, on a storage size roughly 3.2GB spread between two UNIX partitions. (We suggest leaving a little space at the end of the RVM log partition for safety, as RVM automatically adds about one extra page to the amount you specify). Our vice-setup script provides for several default values, the largest of which is 130MB. If you decide to follow the recommendation and use a dedicated partition, creating a 130MB partition will leave plenty of room to expand even if your initial use only suggests a size of 22M, for example.
The log is initialized with rvmutl. At rvmutls prompt, use the command i, and then specify the size of the log segment. In specifying the size, you can use M for megabyte and K for kilobyte. For example, to initialize a log on partition 0g to eight megabytes:
#rvmutl *i Enter name of log file or device:/dev/sdc1 Enter length of log data area:22M *q
The data segment contains the meta-data of the system such as volume headers, Coda directories, resolution logs, etc. The size of the data segment depends on the amount of disk space for file data, i.e. the size of the /vicep? partitions. As a rule of thumb, you will need about 3-5% of the total file data space for recoverable storage. We currently use 4% as a good value under most circumstances. In our systems the data segment is 90Meg for approximately 3.2 gigabytes of disk space. By making it smaller, you can reduce server startup time. However, if you run out of space on the RVM Data partition, you will be forced to reinitialize the system, a costly penalty. So, plan accordingly.
In initializing (or reinitializing), you need to pick several parameters. The first is the starting address of the recoverable segment in your address space. On our servers we start the RVM segment at 0x50000000 for both Linux and BSD based systems on Intel architecture. The second is the amount of space to give the recoverable heap. The heap will obviously grow over use, so plan accordingly. Our heap space is 0x1000000. We suggest that for the last parameters you use 1Meg (0x100000) for the static area, use 80 free lists (or nlists), and a chunksize of 32. These numbers will work well with the internal structure of the file server and are provided as the default vales in the setup script vice-setup.
To perform the data initialization, run the program rdsinit. rdsinit takes two parameters, the names of the RVM log and data devices. For example, to initialize one of our Intel based servers:
# rdsinit /dev/hdc1 /dev/sdb1 Enter the length of the device /dev/hdc1:119070700 Going to initialize data file to zero, could take awhile. done. rvm_initialize succeeded. starting address of rvm: 0x50000000 heap len: 0x1000000 static len: 0x100000 nlists: 80 chunksize: 32 rds_zap_heap completed successfully. rvm_terminate succeeded.
Note: Use of the decimal value for the length of the device and the use of hex values for the address and lengths of the next three values.
The update monitor is used to propagate changes to the Coda server databases to all servers from the SCM. Client update processes run on all the Coda servers and connect to a server update process running on the SCM. The server process uses the file /vice/db/files to determine which files should be kept consistent on all the servers. See the updateclnt(8) and updatesrv(8) man pages for more details.
Create the file /vice/db/files on the SCM. Currently our /vice/db/files looks like this:
ROOTVOLUME VLDB auth2.pw auth2.tk auth2.tk.BAK auth2.lock servers prot_users.db prot_index.db volutil.tk update.tk VRDB files VSGDB dumplist
Coda uses an authentication database that is separate from the UNIX password file. This database is maintained by the SCM. When someone authenticates to Coda, their password is checked against this database and that person is issued a token if they successfully authenticate.
On servers other than the SCM, the Update monitor will ensure that the proper database files are propagated from the SCM. However, you must copy the file /vice/db/update.tk to the new server for the Update monitor to work.