A single name space. All of Coda appears under a single directory
/coda on the client (or under a single drive under Windows). Coda does not
have different exports or shares as do NFS and Samba that are individually
mounted. Under /coda the volumes (aka file sets) of files exported by all
the servers (living in your Coda cell) are visible . Coda automatically finds
servers and all a client needs to know is the name of one bootstrap server
that gives it information how to find the root volume of Coda.
Coda cell. Cell is a group of servers sharing one set of configuration
databases. A cell can consist of a single server or up to hundreds of servers.
One server is designated as the SCM - the System Control Machine. It is distinguished
by being the only server modifying the configuration databases shared by all
servers, and propagating such changes to other servers. At present a Coda
client can belong to a single cell. We hope to get a cell mechanism into
Coda whereby a client can see files in multiple cells.
Coda volumes. File servers group the files in volumes. A volume is
typically much smaller than a partition and much larger than a directory.
Volumes have a root and contain a directory tree with files. Each volume is
"Coda mounted" somewhere under /coda and forms a subtree of the /coda. Volumes
can contain mountpoints of other volumes. A volume mountpoint is not a Unix
mountpoint or Windows drive - there is only one drive or Unix mountpoint
for Coda. A Coda mountpoint contains enough information for the client to
find the server(s) which store the files in the volume. The group of servers
serving a volume is called the Volume Storage Group of the volume.
Volume Mountpoints. One volume is special, it is the root volume,
the volume which Coda mounts on /coda. Other volumes are grafted into the
/coda tree using cfs mkmount. This command installs a volume mountpoint in
the Coda directory tree, and in effect its result is similar to mkdir mountpoint;
mount device mountpoint under Unix. When invoking the cfs mkmount the two
arguments given are the name of the mountpoint and the name of the volume
to be mounted. Coda mountpoints are persistent objects, unlike Unix mountpoints
which needs reinstating after a reboot.
Data storage. The servers do not store and export volumes as directories
in the local disk filesystem, like NFS and Samba. Coda needs much more meta
data to support server replication and disconnected operation and it has complex
recovery which is hard to do within a local disk filesystem. Coda servers
store files identified by a number typically all in a directory tree in /vicepa.
The meta data (owners, access control lists, version vectors) is stored in
an RVM data file which would often be a raw disk partition.
RVM. RVM stands for Recoverable Virtual Memory. RVM is a transaction
based library to make part of a virtual address space of a process persistent
on disk and commit changes to this memory atomically to persistent storage.
Coda uses RVM to manage its metadata. This data is stored in an RVM data file
which is mapped into memory upon startup. Modifications are made in VM and
also written to the RVM LOG file upon committing a transaction. The LOG file
contains committed data that has not yet been incorporated into the data
file on disk.
Client data. Data on the client is stored somewhat similarly: meta
data in RVM (typically in /usr/coda/DATA) and cached files are stored by number
under /usr/coda/venus.cache. The cache on a client is persistent. This cache
contains copies of files on the server. The cache allows for quicker access
to data for the client and allows for access to files when the client is
not connected to the server.
Validation. When Coda detects that a server is reachable again it
will validate cached data before using it to make sure the cached data is
the latest version of the file. Coda compares cached version stamps associated
with each object, with version stamps held by the server.
Authentication. Coda manages authentication and authorization through
a token. Similar (the details are very different) to using a Windows share,
Coda requires users to log in. During the log in process, the client acquires
a session key, or token in exchange for a correct password. The token is associated
with a user identity, at present this Coda identity is the uid of the user
performing the log in.
Protection. To grant permissions the cache manager and servers use
the token with its associated identity and match this against priviliges granted
to this identity in access control lists (ACL). If a token is not present,
anonymous access is assumed, for which permissions are again granted through
the access control lists using the System:AnyUser identity.