<!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: Common Scenarios </TITLE>
<LINK HREF="manual-4.html" REL=next>
<LINK HREF="manual-2.html" REL=previous>
<LINK HREF="manual.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="manual-4.html">Next</A>
<A HREF="manual-2.html">Previous</A>
<A HREF="manual.html#toc3">Contents</A>
<HR>
<H2><A NAME="SystemOverview"></A> <A NAME="s3">3. Common Scenarios </A></H2>
<P>There are several common scenarios that you may encounter. This
chapter attempts to list as many of them as possible and suggest how to
handle each scenario.
<P>
<H2><A NAME="ConstructHoard"></A> <A NAME="ss3.1">3.1 Constructing a hoardfile </A>
</H2>
<P>Coda allows you to give files priorities that affect the cache
manager. The higher the priority,
the lower the possibility that a file will get flushed from the cache
to make space for a another file. These priorities are stored in a
hoard database internal to Venus. This database is preserved across
invocations of Venus, but will be erased when Venus is re-initialized.
<P>The best way to set up a hoard database is by creating hoard files. After
you've created the files once, you do not need to do it again for that set of
files. You can create a hoard file by hand or by using the <EM>spy</EM>
program. See the <B>hoard</B>(1) man page for more details.
<P>To run <EM>spy</EM>:
<OL>
<LI> Run spy in the background, redirecting its output to a file.</LI>
<LI> Run all of the programs and access files you want to hoard.</LI>
<LI> Send a SIGTERM to spy (Do not use ^C)</LI>
<LI> Sort the output file, removing duplicates</LI>
<LI> Remove unnecessary entries</LI>
<LI> On each line add <CODE>a</CODE> at the beginning and a priority at the end</LI>
</OL>
<P>The following is an example of creating a hoard file for gnu-emacs.
Note that while running gnu-emacs, I explicitly enter "scribe mode."
This makes sure that the scribe-specific files are fetched.
<P>
<HR>
<PRE>
% spy > gemacs.out &
[1] 316
% gnu-emacs
% kill %1
%
[1] Done spy > gemacs.out
sort -u gemacs.out > gemacs.hdb
% cat gemacs.hdb
/coda
/coda/i386_mach/omega/usr/local/emacs
/coda/i386_mach/omega/usr/misc/.gnu-emacs
/coda/misc/gnu-emacs/i386_mach/omega/bin/gnu-emacs
/coda/misc/gnu-emacs/i386_mach/omega/lisp/scribe.elc
/coda/misc/gnu-emacs/i386_mach/omega/lisp/term/x-win.el
/coda/misc/gnu-emacs/i386_mach/omega/lisp/x-mouse.elc
/coda/usr
</PRE>
<HR>
<P>Next I would delete the first and last line of the file as I do not
need them. Then add the <B>hoard</B> specific commands. The final file
looks like:
<P>
<HR>
<PRE>
a /coda/i386_mach/omega/usr/local/emacs 600
a /coda/i386_mach/omega/usr/misc/.gnu-emacs 600
a /coda/misc/gnu-emacs/i386_mach/omega/bin/gnu-emacs 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/scribe.elc 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/term/x-win.el 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/x-mouse.elc 600
</PRE>
<HR>
<P>The <CODE>a</CODE> that starts each line tells hoard to "add" the named file
to the database. The 600 that ends each line sets the file's priority.
You may also specify additional attributes for each line. These attributes
are separated from the priority by a ":" and are:
<UL>
<LI><B>c</B> Current children of the given directory will inherit its hoard status.</LI>
<LI><B>c+</B> Current and future children of the given directory will inherit its hoard status.</LI>
<LI><B>d</B> Current descendents of the given directory will inherit its hoard status.</LI>
<LI><B>d+</B> Current and future descendents of the given directory will inherit its hoard status.</LI>
</UL>
<P>For example, to hoard all of the emacs directory, its descendents and
any future descendents, I would include the following line in a
hoardfile:
<P>
<HR>
<PRE>
a /coda/i386_mach/omega/usr/local/emacs 600:d+
</PRE>
<HR>
<P>This ensures you get all of the files you need, but you will use tens
of megabytes of cache space to hoard many files that you do not need,
so oftern you want to be more specific with respect to which files to
hoard.
<P>Other valid command to <EM>hoard</EM> are clear, delete, list, and modify.
See the <EM>hoard</EM>(1) man page for more details on these commands.
<P>
<H2><A NAME="ss3.2">3.2 Hoarding for a Weekend</A>
</H2>
<P>
<A NAME="HoardDB"></A>
One of the most common uses of a Coda laptop is to take it home
overnight or for the weekend. Naturally, you want to be sure that all
of the files that you need over the weekend are in the
cache; otherwise, there is little point in bringing the laptop home.
The <EM>hoard</EM>(1) program helps you do this. Create a hoard file, as
described in Section
<A HREF="#ConstructHoard">XXX</A>, for each project you want
to work on. You may also want hoard files for your personal files,
such as your home directory if its in Coda, and
other tools that you plan on using.
Its best to clear the hoard database whenever you switch projects to
make sure you have enough space in your cache. You might consider
having <EM>clear</EM> as the first command in your personal hoard file. If
you do, make sure you always run hoard with this file before any other
files. Once youve built hoard files for all of your tools and
projects, its simply a matter of running hoard to build the hoard
database you want. When you run <EM>hoard</EM>, you must be logged onto
the machines console, (dont run X). About fifteen minutes before you
are ready to leave, force a hoard walk with the following command:
<HR>
<PRE>
% hoard walk
</PRE>
<HR>
<P>This will cause <EM>venus</EM> to attempt to cache all of the files in the
hoard database. <EM>Wait until the hoard command completes</EM>. You are now
ready to disconnect from the network. You are encouraged to try all
of the commands you intend on using after you disconnect. If you are
missing some files, it will be easy to reconnect and hoard them.
<P>
<P>
<H2><A NAME="ss3.3">3.3 Reintegrating After a Disconnected Session</A>
</H2>
<P>
<A NAME="reintegration"></A>
When you reconnect to the network after a disconnected session, Coda
will automatically try to reintegrate your changes with the Coda
servers. You must be authenticated before reintegration occurs.
Watch the file <EM>/usr/coda/etc/console</EM> with the <B>codacon</B> command
or by running:
<B>tail -f /usr/coda/etc/console</B>.
The reintegrations status will be written to this file.
<P>If the reintegration was successful, the log entries would look like:
<HR>
<PRE>
Reintegrate u.raiff, (1, 244) ( 13:33:43 )
coda: Committing CML for u.raiff ( 13:33:43 )
coda: Reintegrate: u.raiff, result = SUCCESS, elapsed = 2640.0 (15.0, 2609.0,
15.0) ( 13:33:43 )
coda: delta_vm = 0, old stats = [0, 1, 0, 0, 0] ( 13:33:43 )
coda: new stats = [ 0, 0.0, 0.0, 1, 0.2], [ 0, 0.0, 0.0,
0, 0.0] ( 13:33:43 )
</PRE>
<HR>
<P>The following example is from a failed reintegration on the volume
u.raiff.
<HR>
<PRE>
Reintegrate u.raiff, (1, 244) ( 13:27:10 )
coda: Checkpointing u.raiff ( 13:27:10 )coda: to /usr/coda/spool/2534/u.raiff@@%
coda%usr%raiff ( 13:27:10 )
coda: Aborting CML for u.raiff ( 13:27:10 )
coda: Reintegrate: u.raiff, result = 198, elapsed = 2437.0 (15.0, 2265.0, 531.0) ( 13:27:10 )
coda: delta_vm = 1000, old stats = [0, 0, 1, 0, 0] ( 13:27:10 )
coda: new stats = [ 0, 0.0, 0.0, 1, 0.2], [ 0, 0.0, 0.0, 0,
0.0] ( 13:27:10 )
</PRE>
<HR>
<P>Notice that the <EM>change modify log</EM> (CML) was checkpointed to
<EM>/usr/coda/spool/2534/u.raiff@@%coda%usr%raiff</EM>. This file is a tar
file containing the changes that were made on during the disconnected
session. The files in the tar file are relative to the root of
u.raiff. The <B>cfs examineclosure</B> and <B>cfs replayclosure</B> will
show which files were not reintegrated and force a reintegration
respectively.
<P>
<P>
<H2><A NAME="ss3.4">3.4 Dealing With a Flaky Network</A>
</H2>
<P>When the network is acting up, you can use Coda to help isolate
yourself from the networking problems. Set up your hoard database so
that Venus will hoard the files you are working on. Then,
disconnect from the Coda servers with the <B>cfs disconnect</B> command.
To Coda, this is equivalent to physically disconnecting from the network.
<P>Once the network becomes stable, you can use <B>cfs reconnect</B> to
reconnect yourself to the Coda servers and re-integrate your work.
Dont forget to clear your hoard database with <B>hoard clear</B> once
you are done working on the set of files that you hoarded.
<P><EM>Note: AFS will not be affected by cfs, so access to AFS files will
still be affected by the network problems.</EM>
<P>
<H2><A NAME="ss3.5">3.5 Reintegrating Over the Phone Line</A>
</H2>
<P>If you are planning on taking a Coda laptop on an extended trip, you
should consider using SLIP to reinitgrate with the Coda servers
periodically. Using SLIP will allow updates to be visible to
other Coda users, protect against client crashes such as hard drive
failure or theft, and allow you to work on multiple projects,
even when your cache space is not large enough for all of the
projects. By using the following instructions, you can reintegrate
over the phone and change the files in your hoard database.
<P>1. Read the <EM>dialup</EM> manual page, and
<EM>/afs/cs/help/03-Communication/03-Tcons_and_Dialups/slip.doc</EM>
<EM>/afs/cs/help/03-Communication/03-Tcons_and_Dialups/cisco_tcon.doc</EM>
<P>2. Get an account on a terminal server from facilities. This server
is the name that you will use when you start slip.
<P>3. Connect to the terminal server and start slip.
<P>4. Run <CODE>/etc/slattach /dev/com{0,1}</CODE> speed. If you are using the
internal modem, specify /dev/com0 and 2400. If you are using
an external modem, use /dev/com1 and whatever speed (9600).
<P>5. Exit your communications program (kermit, whatver).
slattach holds the line open.
<P>6. Now you have to reset the routes in your routing table.
First delete the old routes:
<P>
<HR>
<PRE>
% set slipaddr = 128.2.254.129 # address of ts2.srv.cs.cmu.edu
% set gwaddr = 128.2.254.36 # address of gw.cs.cmu.edu
% /etc/route delete 0 $gwaddr
% /etc/route delete net 128.2 $hostaddr
% /etc/route -f delete $hostaddr $hostaddr
</PRE>
<HR>
and config the slip interface up with the new routes:
<HR>
<PRE>
% /etc/ifconfig sl0 $hostaddr $slipaddr -trailers up
% /etc/route add net 128.2 $slipaddr 0
% /etc/route add 0 $slipaddr 1
</PRE>
<HR>
If youve started up disconnected, you will also have to run the
command:
<HR>
<PRE>
% ifconfig par0 down
</PRE>
<HR>
<P>Finally, tell Coda to see which servers it can communicate with:
<HR>
<PRE>
% cfs checkservers
</PRE>
<HR>
<P>Your laptop will now behave as if it is on the network. Response
time to commands will be sluggish.
<P>If you want to stop running SLIP before you shut down your computer,
simply turning off your modem or killing <EM>slattach</EM> will terminate
your SLIP connection.
<P>
<H2><A NAME="ss3.6">3.6 Repairing an Inconsistent Directory</A>
</H2>
<P>
<A NAME="Inconsistent"></A>
Occasionally, a directory entry will become inconsistent. This
happens when there is a conflict between file server replicas that Coda cannot
automatically resolve or a reintegration failed because of a local update the
conflicts with the global state. The most common causes of a conflict are when
the file servers are partitioned and a file is changed on more than
one of the partitions or when a disconnected client updates a file that is
also updated on the servers. When this happens, the directory containting
the conflict will now look like a symbolic link and will be pointing
to its <EM>fid</EM>. For example, if a directory, <EM>conflict</EM>, is
inconsistent, it will now appear as:
<HR>
<PRE>
% ls -l conflict
lr--r--r-- 1 root 27 Mar 23 14:52 conflict -> @@7f0000b3.00000005.0000011a
</PRE>
<HR>
<P>Most applications will return the error File not found when they
try to open a file that is inconsistent. You need to resolve this
conflict by using the <EM>repair</EM>(1) tool.
<P>
<H3>Server/Server Conflicts</H3>
<P>Once you run repair, you need to do a "beginRepair" on the object that
is inconsistent. After "beginRepair" is issued, the inconsistent directory
will have an entry for each of the replicated volumes. You can look at
all of these to decide which copy you want. Use repair to copy the
correct version and clear the inconsistency. In the following example
the file <EM>conflict/example</EM> is replicated on three servers. It has
gone inconsistent.
<P>
<HR>
<PRE>
% ls -lL conflict
lr--r--r-- 1 root 27 Dec 20 13:12 conflict -> @@7f0002ec.000000e3.000005d1
% repair
The repair tool can be used to manually repair files and directories
that have diverging replicas. You will first need to do a "beginRepair"
which will expose the replicas of the inconsistent object as its children.
If you are repairing a directory, you will probably use the "compareDir" and "doRepair" commands.
For inconsistent files you will only need to use the "doRepair" command.
If you want to REMOVE an inconsistent object, use the "removeInc" command.
Help on individual commands can also be obtained using the "help" facility.
* begin conflict
a server-server-conflict repair session started
use the following commands to repair the conflict:
comparedirs
removeinc
dorepair
* ^Z
Stopped
% ls conflict
gershwin.coda.cs.cmu.edu schumann.coda.cs.cmu.edu
% ls conflict/*
conflict/gershwin.coda.cs.cmu.edu:
example
conflict/schumann.coda.cs.cmu.edu:
example
% fg
repair
compare
Pathname of Object in conflict? [conflict]
Pathname of repair file produced? [] /tmp/fix
NAME/NAME CONFLICT EXISTS FOR example
-rw-r--r-- 1 raiff 0 Dec 20 13:10 gershwin.coda.cs.cmu.edu/example
-rw-r--r-- 1 -101 0 Dec 20 13:11 schumann.coda.cs.cmu.edu/example
/coda/project/coda/demo/basic/rep/conflict/gershwin.coda.cs.cmu.edu/example
Fid: (0xb0.612) VV:(0 2 0 0 0 0 0 0)(0x8002f23e.30c6e9aa)
/coda/project/coda/demo/basic/rep/conflict/schumann.coda.cs.cmu.edu/example
Fid: (0x9e.5ea) VV:(2 0 0 0 0 0 0 0)(0x8002ce17.30d56fb9)
Should /coda/project/coda/demo/basic/rep/conflict/gershwin.coda.cs.cmu.edu/example be removed? [no] yes
Should /coda/project/coda/demo/basic/rep/conflict/schumann.coda.cs.cmu.edu/example be removed? [no]
Do you want to repair the name/name conflicts [yes]
Operations to resolve conflicts are in /tmp/fix
* do
Pathname of object in conflict? [conflict]
Pathname of fix file? [/tmp/fix]
OK to repair "conflict" by fixfile "/tmp/fix"? [no] yes
SCHUMANN.CODA.CS.CMU.EDU succeeded
GERSHWIN.CODA.CS.CMU.EDU succeeded
* quit
% ls conflict
example
% exit
</PRE>
<HR>
<P>
<P>
<H3>Local/Global Conflicts</H3>
<P>Local/global conflicts are caused by reintegration failures, which
means that the mutations performed while the client was disconnected
are in conflict with the mutations performed on the servers from other
clients during the disconnection. The objects involved in local/global
conflict are represented in the same fashion as server/server
conflicts, i.e., they become dangling symbolic links.
<P>To start a local/global repair session for an object OBJ, you need to
invoke the repair tool and issue the "beginrepair" command with the
pathname of OBJ as the argument. Once the repair session is started,
both the local and global replicas of OBJ are visible at
OBJ/local (read-only) and OBJ/global (mutable and serving as the
workspace for storing the repair result for OBJ and its descendants).
The central process of repairing the local/global conflicts on OBJ is
to iterate the local-mutations-list containing all the local updates
performed on OBJ or its descendants, which can be displayed by the
"listlocal" command. Each operation in the list must be accounted for
and the repair tool cooperates with Venus to maintain the
current-mutation being iterated. The "checklocal" command can be used
to show the conflict information between the current-mutation and the
global server state. You can advance the iteration to the next
operation using either the "preservelocal" or the "discardlocal"
command with the former replaying the current-mutation operation on
the relevant global replicas. You can also use the "preservealllocal"
and "discardalllocal" commands to speed up the iteration. Because the
global replica OBJ is mutable, existing tools such as "emacs" etc. can
be directly used to make the necessary updates. The "quit" command is
used to either commit or abort the repair session. The man page on
on the repair commands contains more detailed information, and the
following simple example illustrates the main process of repairing a
local/global conflict.
<P>Suppose that during disconnection, a user creates a new directory
<EM>/coda/usr/luqi/papers/cscw/figs</EM> and stores a new version for file
<EM>/coda/usr/luqi/papers/cscw/paper.tex</EM>. However, during the
disconnection his co-author also creates a directory
<EM>/coda/usr/luqi/papers/cscw/figs</EM> and stores some PS files in it. Upon
reintegration a local/global conflict is detected at
<EM>/coda/usr/luqi/papers/cscw</EM>.
<P>
<HR>
<PRE>
% ls -l /coda/usr/luqi/papers/cscw would show
lr--r--r-- 1 root 27 Dec 20 00:36 cscw -> @@7f000279.00000df3.0001f027
% repair
* begin
Pathname of object in conflict? [] /coda/usr/luqi/papers/cscw
a local-global-conflict repair session started
the conflict is caused by a reintegration failure
use the following commands to repair the conflict:
checklocal
listlocal
preservelocal
preservealllocal
discardlocal
discardalllocal
setglobalview
setmixedview
setlocalview
a list of local mutations is available in the .cml file in the coda spool directory
* !ls -l /coda/usr/luqi/papers/cscw
total 4
drwxr-xr-x 3 luqi 2048 Dec 20 00:51 global
drwxr-xr-x 3 luqi 2048 Dec 20 00:51 local
Back to *
* listlocal
local mutations are:
Mkdir /coda/usr/luqi/papers/cscw/local/figs
Store /coda/usr/luqi/papers/cscw/local/paper.tex (length = 19603)
* checklocal
local mutation: mkdir /coda/usr/luqi/papers/cscw/local/figs
conflict: target /coda/usr/luqi/papers/cscw/global/figs exist on servers
* discardlocal
discard local mutation mkdir /coda/usr/luqi/papers/cscw/local/figs
* checklocal
local mutation: store /coda/usr/luqi/papers/cscw/local/paper.tex
no conflict
* preservelocal
store /coda/usr/luqi/papers/cscw/global/paper.tex succeeded
* checklocal
all local mutations processed
* quit
commit the local/global repair session? [yes]
</PRE>
<HR>
<P>
<P>
<HR>
<A HREF="manual-4.html">Next</A>
<A HREF="manual-2.html">Previous</A>
<A HREF="manual.html#toc3">Contents</A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
38
