Optimizing Coda 6.x

Notes on the tricky questions in setting up coda 6 – much of this disagrees with the current documentation.

Last Updated 4/11/2005

Server

RVM (Meta)Data and Log sizes

•Determine the number of files and directories you want to accommodate.  Take expected max number of files times 500 plus expected max number of directories times 3000 and you have your rvm size.  Use the rvmsizer.c utility to make this calculation on an existing file tree and then use some multiple (I used 15) to allow for growth.
•It's no longer necessary to use partitions for rvm metadata or logs from a performance standpoint.  In fact, there may be better performance from using a file.  However, either way, the rvm meta data file or partition will be mapped entirely into memory so you must have enough RAM (+swap, but you don't really want it swapping, do you?) available.
•A log size of 20M should work for any setup
•Note that the size of the RVM is dependent on the number of files and directories across all volumes (not per volume) and has nothing to do with file size.
•It no longer matters what filesystem type the logs, metadata, and file data are stored under.  ext3 is just as efficient as ext2.  reiserfs may create problems.
•A separate partition for file data can be useful in limiting the disk space coda can use and preventing system problems due to disk-full errors.
•It is desirable to have the RVM Log on a separate disk to speed write operations and reduce disk seeks.

Server Volumes

•Volumes are used as administrative units to specify quotas and backup scheduling.
•Certain operations are done per volume.  Coda runs more efficiently with smaller volume sizes and more volumes than the other way around.
•Volume creation and mounting is arbitrary, but volume names should either match or somehow indicate their mount points (slashes are allowed in volume names).
•If you will be frequently moving files between two points in a directory tree, it would be advantageous to have those two points in the same volume so that the file doesn't have to be copied byte-by-byte for the move operation.
•Maximum number of volumes is about 1024 per server.
•There is no hard limit as to the maximum size of a volume, but according to Jan, “at some point the vnode lookup table becomes unmanageable, probably somewhere between 100K and 200K files [on a single volume].”

Backup

•Backup is done by freezing volumes and creating snapshots.  Using the coda backup system allows coda acls, quotas, etc., to be backed up.  tar alone will not backup any file metadata or version information.
•To copy a server manually from one machine to another you could copy your /vicepa files and then use this process to copy the RVM file:
Old server:
# norton-reinit -rvm <log> <data> <datasize> -dump rvmcontents 
New server:
Create empty rvm log and data. (vice-setup-rvm)
# norton-reinit -rvm <log> <data> <datasize> -load rvmcontents 

Client

Client Cache

•The client has its own RVM metadata for the files in its cache.  The RVM data file can't be larger than 1gb, and should be much smaller than the available memory on the client so that coda is not too resource-intensive.  The calculation of RVM size in memory is made in the same way as the server: 500 times number of files plus 3000 times number of directories.  However, the client needs a much larger cushion as cache operations also occur in RVM.  [Calculation details to be added here.]
•Be sure to limit the number of cache files as well as the amount of data in the venus.conf file so you don't overflow your RVM.
•If you put your client cache on a ram drive, your cache will not be persistent between venus restarts.  To accommodate this, put the line, “dontuservm=1” in your venus.conf file.  This will keep the clients very fast and reduce unnecessary disk writes.

Files

•Coda cannot handle a file larger than 2gb (due to 32bit int storing file size) and will be pretty slow and resource intensive for large files under 2gb.
•A client cannot read or write a file larger than the amount of RVM they have available.
•Client must also have enough cache room for the file (which means that a 500mb file copied to /coda will now be using 1gb of disk space on the client.
•Changing unix file or owner permissions (eg using chmod or chown) on a file or directory is useless and may break your coda implementation.  Always use the coda acl facilities (the cfs command) to manage who has what writes to certain directories.