Coda File System

RVM, meta data and VM usage

The Coda fileservers maintain their own view of the file system. Files are referenced by a number, and stored in partitions, typically mounted on /vicepa.

Directory contents and Metadata, such as ownership, size, creation time, but also metadata related to dicsonnected operation (StoreId's) and replication (version vectors, and operation log entries) are stored in the RVM data segment. This segment can be in a file, but is preferrably on a raw disk partition.

Modifications to this segment are made using RVM transactions [see the RVM manual on the Coda www site], and the transaction mechanism involves a LOG, the RVM LOG. The LOG is preferrably stored on a disk by itself, to avoid seeks. Unless log truncation is in progress the log is only accessed in a sequential fashion.

When the server starts, the RVM data is memory mapped. This means that the VM size of the server will be increased by the size of the RVM DATA segment. Presently [Oct 98] this memory is also committed immediately, making startup unnecessarily slow - we are planning to change that.

The size of RVM DATA you need can be computed roughly as follows:

The size of the files is irrelevant.

WARNING: there are situation where you'll need more, for example if you plan to run with a partially available volume storage group for extended time, then the server will make a large number of log entries and you might need considerably more.

Example

So if I want to store 50,000 files in 5,000 directories then I need: 50,000 * 500 + 5,000 * 3,000 = 40MB RVM space.

If these files were 50k on average, you would be storing 2.5GB of file data, if they were 500k on average you'd be storing 25GB of file data.

Practical considerations

At present we recommend not using more than 330MB of RVM. We have a few servers running with more, but the startup time is slow and Coda has too many bugs to warrant installing mega servers at this point.

Scalability:

Our aims are to significantly, but not dramatically improve scalability. Hopefully something like 500,000 files will become a possibility. To achieve this we need to do several things: