<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Coda File System User and System Administrators Manual: System Overview </TITLE>
<LINK HREF="manual-6.html" REL=next>
<LINK HREF="manual-4.html" REL=previous>
<LINK HREF="manual.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="manual-6.html">Next</A>
<A HREF="manual-4.html">Previous</A>
<A HREF="manual.html#toc5">Contents</A>
<HR>
<H2><A NAME="SysOvr"></A> <A NAME="s5">5. System Overview </A></H2>
<P>Each Coda client sees the Coda File System as a single tree,
/coda. In reality this tree is an illusion supported by <EM>system
control machine</EM> (SCM), several dedicated file servers, and a local
area network. One of the servers may double as the (SCM). Figure
<A HREF="#ServerOrg">XXX</A> illustrates the server organization.
<P>
<FIGURE>
<EPS FILE="serverorg">
<CAPTION>
<A NAME="ServerOrg"></A> Typical Coda server organization</CAPTION>
</FIGURE>
<P>
<H2><A NAME="ss5.1">5.1 Machines</A>
</H2>
<P>
<P>The Coda architecture recognizes three types of machines, <EM>clients</EM>,
<EM>servers</EM> and a <EM>system control machine</EM> (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.
<P>
<H2><A NAME="ss5.2">5.2 Processes</A>
</H2>
<P>
<P>Each of the dedicated file servers must run a number of processes.
These processes are shown in Figure
<A HREF="#ServerOrg">XXX</A> and are described
below.
<P>
<CENTER><TABLE BORDER><TR><TD>
<BR>
<B>File Server Process</B></TD><TD> The <EM>codasrv</EM> 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 <CODE>SHUTDOWN</CODE> in the<CODE>/vice/srv</CODE> directory indicates that the server processexited normally. </TD></TR><TR><TD>
<B>Auth Server Process</B></TD><TD> The <EM>auth2</EM> 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 <EM>updateclnt/updatesrv</EM> processesdescribed below.On all servers (except the SCM), auth2 is invoked with the <EM>-chk</EM>option.</TD></TR><TR><TD>
<B>Update Client Process</B></TD><TD>The <EM>updateclnt</EM> process works in conjuctionwith the <EM>updatesrv</EM> 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.
<CAPTION>
<A NAME="ServeProc"></A> Server Processes </CAPTION>
</TD></TR></TABLE></CENTER>
<P>Figure
<A HREF="#ServeProc">XXX</A> lists the typical processes of a
running file server.
<P>
<BLOCKQUOTE><CODE>
<PRE>
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
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2><A NAME="ss5.3">5.3 Data Location</A>
</H2>
<P>The information stored on Coda servers is organized into several
directories. These directories are are described below.
<P>
<UL>
<LI><B>/vice/auth2</B> This directory contains information related to
the authentication process, including its log file.</LI>
<LI><B>/vice/bin</B> contains the Coda file system
binaries for servers and the SCM.</LI>
<LI><B>/vice/db</B>contains the log file for the update
processes as well as a number of databases important to servers.</LI>
<LI><B>/vice/srv</B>contains information related to
the server process, including its log file.</LI>
<LI><B>/vice/vol</B> contains information related to
the volumes contained in the Coda file system.</LI>
<LI><B>/vice/vol/remote</B> exists only on the SCM and
contains volume information for all remote servers.</LI>
</UL>
<P>A more detailed description of the files in the these directories is
listed in Appendix
<A HREF="manual-16.html#SysFiles">XXX</A>.
<P>
<H2><A NAME="ss5.4">5.4 File System Consistency</A>
</H2>
<P>
<P>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 <EM>salvager</EM>, 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.
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<HR>
<A HREF="manual-6.html">Next</A>
<A HREF="manual-4.html">Previous</A>
<A HREF="manual.html#toc5">Contents</A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
40
