Coda File System User and System Administrators Manual: System Overview

Next Previous Contents

## 5. System Overview

Each Coda client sees the Coda File System as a single tree, /coda. In reality this tree is an illusion supported by system control machine (SCM), several dedicated file servers, and a local area network. One of the servers may double as the (SCM). Figure XXX illustrates the server organization.

Typical Coda server organization

## 5.1 Machines

The Coda architecture recognizes three types of machines, clients, servers and a system control machine (or SCM). Client machines are typically single-user workstations used to access shared information. These machines are not trusted by servers except for the duration of a login session by an authenticated user. Server machines are secure, trusted machines whose purpose is to service client requests for shared data. As the custodians of shared information, servers must require authentication of each user before releasing shared data to the users client workstation. The third machine type is the system control machine (SCM). The purpose of the SCM is to provide a single point of control for ease of administration. Logically, the SCM is distinct from the servers, but, physically, the SCM can also act as a server.

## 5.2 Processes

Each of the dedicated file servers must run a number of processes. These processes are shown in Figure XXX and are described below.

File Server Process | The codasrv process interacts withthe venus process on clients. Together they fulfill user requests for shareddata stored on the server. When started, the server process will salvage thefile system. The presence of a file called `SHUTDOWN` in the`/vice/srv` directory indicates that the server processexited normally.
Auth Server Process | The auth2 process runs on allservers. It validates user passwords and issues a token for that userif the password is correct. However, passwords may only be changedat the SCM. Hence,the password database is read-only replicated to all servers and the SCMmaintains the read-write replica. Changes to the password file areupdated automatically through the updateclnt/updatesrv processesdescribed below.On all servers (except the SCM), auth2 is invoked with the -chkoption.
Update Client Process | The updateclnt process works in conjuctionwith the updatesrv process (running on the SCM) to keepread-only copies of system files and databases in sync with theircorresponding read-write copy. The updateclnt process checks with theupdatesrv process on the SCMperiodically to ensure that the read-only copy on this server isthe latest copy. Thus, when the read-write copy is updated, the read-onlycopies will be automatically updated after some delay. Server Processes

Figure XXX lists the typical processes of a running file server.

> `

>       PID TT STAT  TIME COMMAND
>         0 ?  R <   53hr  (kernel idle)
>         1 ?  SW    0:00     init -a (init)
>         2 ?  U <  10:00  (inode_pager)
>         3 ?  S <   0:00  (device pager)
>         4 ?  S <   0:00  (device server)
>         5 ?  S     0:00  (exception hdlr)
>         6 ?  SW    0:00 /etc/mach_init -a
>       152 ?  SW    0:00 updatesrv       -s -p /vice/db
>       156 ?  SW    0:00 auth2
>       179 ?  SW    3:19 /etc/update
>       182 ?  SW    0:00 /etc/cron
>       190 ?  SW    0:07 /usr/cs/etc/nanny -init /usr/cs/etc/nanny.config
>       202 ?  SW    0:00 /etc/inetd
>       203 ?  SW    0:07 /etc/named
>       204 ?  SW    0:00 /usr/cs/etc/supfilesrv
>       205 ?  SW    0:00 /usr/cs/lib/lpd -l
>       206 ?  SW    0:00 RFS Listener.
>      1217 ?  SW    0:00 sh /vice/bin/startserver
>      1222 ?  S     6:56 codasrv           -time -maxworktime 15 -nodumpvm -trunc 1 -rvm
>     /dev/rrz3c /dev/rrz0h 69206016
>      1358 t0 R     0:00 ps axww

> `

## 5.3 Data Location

The information stored on Coda servers is organized into several directories. These directories are are described below.

- /vice/auth2 This directory contains information related to the authentication process, including its log file.
- /vice/bin contains the Coda file system binaries for servers and the SCM.
- /vice/dbcontains the log file for the update processes as well as a number of databases important to servers.
- /vice/srvcontains information related to the server process, including its log file.
- /vice/vol contains information related to the volumes contained in the Coda file system.
- /vice/vol/remote exists only on the SCM and contains volume information for all remote servers.

A more detailed description of the files in the these directories is listed in Appendix XXX.

## 5.4 File System Consistency

After a crash, many subsystems of Coda must be checked to maintain file system consistency. To ensure that Coda data partitions are internally consistent, CMUs modified version of fsck, is run during reboot. Coda accesses files by inode rather than name. The normal fsck would toss out Coda files because they have no name. The salvager, run by the file process during initialization, checks that every inode is referenced by at least one Coda directory. Thus, CMUs fsck and salvage together provide what fsck normally provides for the Unix file system. The reason fsck is not a sufficient check on Coda file systems is that it does not recognize Coda directories (Coda directories appear to be regular files in the Unix file system) so it cannot perform the inode reference check.

Next Previous Contents