Sophie: coda-doc-5.2.0-4mdk noarch

coda-doc-5.2.0-4mdk.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
 <TITLE>The Coda HOWTO: Coda's ingredients </TITLE>
 <LINK HREF="coda-howto-2.html" REL=next>

 <LINK HREF="coda-howto.html#toc1" REL=contents>
</HEAD>
<BODY>
<A HREF="coda-howto-2.html">Next</A>
Previous
<A HREF="coda-howto.html#toc1">Contents</A>
<HR>
<H2><A NAME="s1">1. Coda's ingredients </A></H2>

<P>
<P>
<H2><A NAME="ss1.1">1.1 What is Coda ? </A>
</H2>

<P> 
<P>Coda is a distributed file system, i.e. it makes files available to a
collection of client computers as part of their directory tree, but
ultimately maintains the authoritative copy of the file data on
servers. Coda has some features that make it stand out: it supports
<EM>disconnected operation</EM>, i.e. full access to a cached section of
the file space during voluntary or involuntary network or server
outages. Coda will automatically reintegrate the changes made on
disconnected clients when reconnecting.  Further Coda has read write,
failover server replication, meaning that data is stored and fetch
from any of a group of servers and Coda will continue to operate when
only a subset of all servers is available.  If server differences
arise due to <EM>network partitions</EM> Coda will resolve differences
automatically to a maximum extent possible and aid users in repairing
what can't be done automatically. Coda is very differently organized
from NFS and Windows/Samba shares.  Coda does have many similarities
to AFS and DCE/DFS.
<P>
<H2><A NAME="ss1.2">1.2 Getting clued in with the Coda terminology </A>
</H2>

<P>
<P>
<DL>
<DT><B>A single name space</B><DD><P>All of Coda appears under a single directory
<CODE>/coda</CODE> on the client (or under a single drive under Windows).
Coda does not have different exports or shares as do NFS and Samba
that are individually mounted.  Under <CODE>/coda</CODE> the volumes (aka
file sets) of files exported by all the servers (living in your Coda
cell) are visible.  Coda automatically finds servers and all a client
needs to know is the name of one bootstrap server that gives it
information how to find the root volume of Coda.
<P>
<DT><B>A Coda cell</B><DD><P>is a group of servers sharing one set of
configuration databases.  A cell can consist of a single server or up
to hundreds of servers. One server is designated as the <B>SCM</B>,
the system Control machine.  It is distinguished by being the only
server modifying the configuration databases shared by all servers,
and propagating such changes to other servers. At present a Coda
client can belong to a single cell.  We hope to get a cell mechanism
into Coda whereby a client can see files in multiple cells.
<P>
<DT><B>Coda volumes:</B><DD><P>File servers group the files in volumes.  A volume
is typically much smaller than a partition and much larger than a
directory.   Volumes have a root and contain a directory tree with
files. Each volume is "Coda mounted" somewhere under /coda and
forms a subtree of the /coda.  Volumes can contain mountpoints of
other volumes.  A volume mountpoint is not a Unix mountpoint or
Windows drive - there is only one drive or Unix mountpoint for Coda.
A Coda mountpoint contains enough information for the client to find
the server(s) which store the files in the volume.  The group of
servers serving a volume is called the <EM>Volume Storage Group</EM>
of the volume.
<P>
<DT><B>Volume Mountpoints</B><DD><P>One volume is special, it is the root volume,
the volume which Coda mounts on <CODE>/coda</CODE>.  Other
volumes are grafted into the <CODE>/coda</CODE> tree using the
<B> cfs makemount</B>.  This command installs a volume
mountpoint in the Coda directory tree, and in effect its result is
similar to <B> mkdir mountpoint ; mount device mountpoint</B> under Unix.  When invoking the <B> cfs
makemount</B> the two arguments given are the name of the
mountpoint and the name of the volume to be mounted.  Coda mountpoints
are persistent objects, unlike Unix mountpoints which needs
reinstating after a reboot.
<P>
<DT><B>Data storage</B><DD><P>The servers do not store and export volumes as
directories in the local disk filesystem, like NFS and Samba.  Coda
needs much more meta data to support server replication and
disconnected operation and it has complex recovery which is hard to do
within a local disk filesystem.  Coda servers store files identified
by a number typically all under a directory <CODE>/vicepa</CODE>.  The
meta data (owners, access control lists, version vectors) and
directory contents is stored in an RVM data file which would often be
a raw disk partition.
<P>
<DT><B>RVM</B><DD><P>stands for <EM>Recoverable Virtual Memory</EM>.  RVM is a
transaction based library to make part of a virtual address space of a
process persistent on disk and commit changes to this memory
atomically to persistent storage. Coda uses RVM to manage its
metadata.  This data is stored in an RVM data file which is mapped
into memory upon startup. Modifications are made in VM and also
writtent to the RVM LOG file upon committing a transaction.  The LOG
file contains committed data that has not yet been incorporated into
the data file on disk.
<P>
<DT><B>Client data</B><DD><P>is stored somewhat similarly: meta data in RVM
(typically in <CODE>/usr/coda/DATA</CODE>) and cached files are stored by
number under <CODE>/usr/coda/venus.cache</CODE>.  The cache on a client is
persistent.  This cache contains copies of files on the server.  The
cache allows for quicker access to data for the client and allows for
access to files when the client is not connected to the server.
<P>
<DT><B>Validation</B><DD><P>When Coda detects that a server is reachable again it
will <EM>validate</EM> cached data before using it to make sure the cached
data is the latest version of the file.  Coda compares cached version
stamps associated with each object, with version stamps held by the
server.
<P>
<DT><B>Authentication</B><DD><P>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.
<P>
<P>
<DT><B>Protection</B><DD><P>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.
<P>
<P>
<P>
</DL>
<P>
<H2><A NAME="ss1.3">1.3 Organization of the client </A>
</H2>

<P>
<P>
<H3>The kernel module and the cache manager </H3>

<P>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
<B>Venus</B>.   User requests enter the kernel, which will
either reply directly or ask the cache manager <B>venus</B> to
assist in service.
<P>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 <CODE>/coda</CODE>. 
<P>
<H3>Utilities </H3>

<P> 
<P>To manipulate acl's, the cache, volume
mountpoints and possibly the network behaviour of a Coda client a
variety of small utilities is provided. The most important one is the
<B>cfs </B> command.
<P>There is also a <B>clog</B> program to authenticate to the Coda
authentication server.  The <B>codacon</B> programm allows one to
monitor the operatoin of the cache manager, and <B>cmon</B> program
gives summary information about a list of servers.
<P>
<P>
<H2><A NAME="ss1.4">1.4 The server organization </A>
</H2>

<P>
<P>The main program is the Coda fileserver <B>codasrv</B>.  It is
responsible for doing all file operations, as well as volume location
service.
<P>The Coda authentication server <B>auth2</B> handles requests from
<B>clog</B> for tokens, and changes of password from <B>au</B> and
<B>cpasswd</B>.  Only the the auth2 process on the SCM will modify
the password database.
<P>All servers in a Coda cell share the configuration databases in
<CODE>/vice/db</CODE> and retrieve them from the SCM when changes have
occurred.  The <B>updateclnt</B> program is responsible for
retrieving such changes, and it polls the <B>updatesrv</B> on the
SCM to see if anything has changed.  Sometimes the SCM needs a
(non-shared) database from another server to update a shared database.
It fetches this through an <B>updatesrv</B> process on that server
using <B>updatefetch</B>.
<P>
<H3>Utilities </H3>

<P>
<P>On the server there are utilities for volume creation and management.
These utilities consist of shell scripts and the volutil command.
There is also a tool to manipulate the protection databases.
<P>
<HR>
<A HREF="coda-howto-2.html">Next</A>
Previous
<A HREF="coda-howto.html#toc1">Contents</A>
</BODY>
</HTML>