(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
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.
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.
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 -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.
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
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 .
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.