Chapter 1. Basic concepts

Table of Contents
The client
The servers

Coda is a distributed filesystem which is substantially differently organized than NFS. This chapter introduces the concepts and describes the organization of Coda clients and file servers. If you are familiar with AFS, much of this will be known.

The client

Here we will briefly explain the organization of a Coda client.

Namespace

Unlike NFS, Samba and AppleTalk, Coda has a single name space. This means that there is a single mountpoint typically /coda. Under this mountpoint Coda unifies all volumes of files exported by all the fileservers.

Discovery of servers is automatic: all Coda needs is the name of one or more servers. A coda client will contact this server and ask it for the root volume, which is the directory tree to be mounted on /coda.

Coda has a single Unix file system mountpoint, or a single device under Windows. Internally, Coda handles volume mount points, but these are transparent to the user, i.e. mount will not reveal volume mountpoints.

The kernel module and the cache manager

Like every filesystem a computer enabled to use the Coda filesystem needs kernel support to access Coda files. Coda's kernel support is minimal and works in conjunction with the cache manager Venus. User requests enter the kernel, which will either reply directly or ask the cache manager venus to assist in service.

Typically the kernel code is in a kernel module, which is either loaded at boot time or dynamically loaded when Venus is started. Venus will even mount the Coda filesystem on /coda.

Configuration of the client

The configuration of the client is minimal. A single file /usr/coda/etc/vstab holds the names of a few servers to bootstrap.

Apart from this configuration file, a Coda client needs a cache directory, currently in /usr/coda/venus.cache. The vstab file also holds the maximum size of the cache.

Coda uses a few UDP ports, and optionally a single TCP port. The names of these ports have to be present in the services file.

Other aspects of the client

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.

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.

To manipulate acl's, the cache and possibly the network behaviour of a Coda client a variety of small utilities is provided. The most important one is the cfs command.