Coda File System

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.

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.

Server Processes

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 -chk option.
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.

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

    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.

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