<!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: Unix Manual Pages </TITLE>
<LINK HREF="manual-18.html" REL=previous>
<LINK HREF="manual.html#toc19" REL=contents>
</HEAD>
<BODY>
Next
<A HREF="manual-18.html">Previous</A>
<A HREF="manual.html#toc19">Contents</A>
<HR>
<H2><A NAME="ManPages"></A> <A NAME="s19">19. Unix Manual Pages </A></H2>
<P>
<P>\newpage
<H2><A NAME="ss19.1">19.1 cfs(1) </A>
</H2>
<P>
NAME
<H3></H3>
<P>cfs - Coda File System Interface Program
<P>
SYNOPSIS
<H3></H3>
<P><B>cfs bandwidth</B> <speed>
<P><B>cfs checkpointml</B>
<P><B>cfs checkservers</B>
<P><B>cfs checkvolumes</B>
<P><B>cfs clearpriorities</B>
<P><B>cfs compress</B> <file> [<file> <file> ...]
<P><B>cfs [@cpu|@sys]</B>
<B>cfs disconnect</B>
<P><B>cfs endrepair</B> <file>
<P><B>cfs examineclosure</B>
<P><B>cfs flushcache</B>
<P><B>cfs flushobject</B> <obj> [<obj> <obj> ...]
<P><B>cfs flushvolume</B> <dir> [<dir> <dir> ...]
<P><B>cfs getfid</B> <path> [<path> <path> ...]
<P><B>cfs getpath</B> <fid> [<fid> <fid> ...]
<P><B>cfs getmountpoint</B> <volid>
<P><B>cfs listacl</B> <dir> [<dir> <dir> ...]
<P><B>cfs listcache</B> [<dir> <dir> ...]
<P><B>cfs listvol</B> <dir> [<dir> <dir> ...]
<P><B>cfs lsmount</B> <dir> [<dir> <dir> ...]
<P><B>cfs mkmount</B> <directory> <volume name> [-rw]
<P><B>cfs purgeml</B>
<P><B>cfs reconnect</B>
<P><B>cfs replayclosure</B>
<P><B>cfs rmmount</B> <dir> [<dir> <dir> ...]
<P><B>cfs setacl</B> [-clear] [-negative] <dir> <id> <rights> [<id> <rights> ....]
<P><B>cfs slow</B> <speed (bps)>
<P><B>cfs truncatelog</B>
<P><B>cfs uncompress</B> <file> [<file> <file> ...]
<P><B>cfs waitforever</B> [-on] [-off]
<P><B>cfs whereis</B> <dir> [<dir> <dir> ...]
<P><B>cfs writedisconnect</B> [-age <secs> -time <secs> <dir> ]
<P><B>cfs writereconnect</B> [<dir> <dir> ...]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>cfs</B> allows users to perform operations specific to the Coda File
System. Most often, people use it to see how much of their allocated
storage space they are currently using and to change the protection on
their personal directories. <B>cfs</B> will change the protection or
"rights" on directories but not on individual files. To change
permissions on individual files, use <EM>chmod (1)</EM>.
<P>
<DL>
<DT><B><B>bandwidth</B></B><DD><P>Provide a hint about network
speed. Use this command to tell venus your networks speed in bits
per second.
<P>Abbreviation: <B>bw</B>.
<P>
</DL>
<P>
<DL>
<DT><B><B>checkpointml</B></B><DD><P>Checkpoint volume modify log. This command
will create a checkpoint file
<CODE>/usr/coda/spool/<uid>/<vol>@<mountpt></CODE>. Where
<CODE><uid></CODE> is your <B>cfs</B> user id, <CODE><vol></CODE> is
the volume being checkpointed, and <CODE><mountpt></CODE> is the volume's
mount point.
<P> Abbreviation: <B>ck</B>.
<P>
</DL>
<P>
<DL>
<DT><B><B>checkservers</B></B><DD><P>Check the status of the Coda
file servers. Report on servers that are down.
<P>
</DL>
<P>
<DL>
<DT><B><B>checkvolumes</B></B><DD><P>Check volume/name mappings.
<P>
</DL>
<P>
<DL>
<DT><B><B>clearpriorities</B></B><DD><P>Clear short-term priorities
used for cache management.
<P>
</DL>
<P>
<DL>
<DT><B><B>compress</B></B><DD><P>compress given files in the cache.
these files will be uncompressed automatically if they are touched or
can be explicitely uncompressed with the <EM>cfs uncompress</EM> command.
<P>
</DL>
<P>
<DL>
<DT><B><B>@cpu or @sys</B></B><DD><P>When the end of a pathname component is
either @sys or @cpu, the local venus will replace these magic strings with
a platform dependent string. These cfs commands can be used to check what
the precise expansion values depending on the current OS/cpu.
<P>
</DL>
<P>
<DL>
<DT><B><B>disconnect</B></B><DD><P>Partition your client from the
Coda file servers.
<P>
</DL>
<P>
<DL>
<DT><B><B>endrepair</B></B><DD><P>Tell venus to end a repair session
on file. Useful if repair is exits without finishing the repair
session.
<P>Abbreviation: <B>er</B>.
<P>
</DL>
<P>
<DL>
<DT><B><B>examineclosure</B></B><DD><P>Examine reintegration closure. Using
<B>cfs examineclosure</B> will display the fixfile used to reintegrate changes that
were made while operating in disconnected mode.
<P>Abbreviation: <B>ec</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>flushcache</B></B><DD><P>Flush entire cache. Care must be taken when
using the <B>cfs flushcache</B> command, as flushing the cache while operating in
disconnected mode may result in loss of data.
<P>
</DL>
<P>
<DL>
<DT><B><B>flushobject</B></B><DD><P>Flush objects from cache. <B>cfs
flushobject</B> tells venus to remove the given objects from the cache.
<P>Abbreviation: <B>fl</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>flushvolume</B></B><DD><P>Flush all data in specified volumes. Care must be
taken when using the <B>cfs flushvolume</B> command, as flushing the cache while
operating in disconnected mode may result in loss of data.
<P>
</DL>
<P>
<DL>
<DT><B><B>getfid</B></B><DD><P>Map the given paths to Coda file ids.
<P>Abbreviation: <B>gf</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>getpath</B></B><DD><P>Map fid to volume-relative path. <B>cfs
getpath</B> will display the path for each of the given fids.
<P>Abbreviation: <B>gp</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>listacl</B></B><DD><P>List access control list for each of the given
directories.
<P>Abbreviation: <B>la</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>listcache</B></B><DD><P>List the contents of the entire
cache or the given volumes (directories).
<P>Abbreviation: <B>lc</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>listvol</B></B><DD><P>Display the current status of the volume in
which the directory is stored.
<P>Abbreviation: <B>lv</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>lsmount</B></B><DD><P>List the countents of a mount point. This
command can be used to tell what volume a mount point refers to.
<P>
</DL>
<P>
<DL>
<DT><B><B>mkmount</B></B><DD><P>Create a mount point. Mount <EM>volume name</EM> at
the point in the file system described by <EM>filename</EM>. If the <EM>-rw</EM> flag is
set, never use the corresponding read-only volume for a volume. Otherwise, if a
read-only volume exists (and the parent is also a read-only volume), use the
read-only volume.
<P>Abbreviation: <B>mkm</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>purgeml</B></B><DD><P>Purge volume modify log. Care must be taken
when using the <B>cfs purgeml</B> command, as it may result in loss of data.
<P>
</DL>
<P>
<DL>
<DT><B><B>reconnect</B></B><DD><P>Reconnect to the Coda file
servers. <B>cfs reconnect</B> will undo the effects of a <EM>cfs
disconnect</EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>replayclosure</B></B><DD><P>Replay reintegration closure.
<P>Abbreviation: <B>rc</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>rmmount</B></B><DD><P>Remove a mount point from the file system.
The volume itself is not changed.
<P>Abbreviation: <B>rmm</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>setacl</B></B><DD><P>Set access control list. Sets the access
control list for each <EM>id</EM>. The <EM>-clear</EM> switch clears the access control
list except for the entries given on the call to <B>cfs</B>. The <EM>-negative</EM>
switch denies the given permissions, rather than granting them. <EM>Rights</EM> are
a subset of <EM>rwidlak</EM> which are read, write, insert, delete, lookup,
administer, and lock respectively. See the section on <EM>File Protection</EM> in
the Coda manual for more detail.
<P>Abbreviation: <B>sa</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>slow</B></B><DD><P>Set network speed to the given speed in bits per
second.
<P>
</DL>
<P>
<DL>
<DT><B><B>truncatelog</B></B><DD><P>Truncate the RVM log at this instant.
<P>Abbreviation: <B>tl</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>uncompress</B></B><DD><P>Uncompress given cached files.
<EM>venus</EM> will automatically uncompress any compressed files that it touches in the cache.
<P>
</DL>
<P>
<DL>
<DT><B><B>waitforever</B></B><DD><P>Tells venus whether it should wait
forever for dead file servers or not. By default, venus does not wait; it
returns ETIMEDOUT. For certain batch jobs, waiting is better than not waiting.
<P>Abbreviation: <B>wf</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>whereis</B></B><DD><P>List the servers that the given files reside
on.
<P>
</DL>
<P>
<P>
<DL>
<DT><B><B>writedisconnect</B></B><DD><P>Tell venus to write disconnect on
the given volumes, or all volumes if none are provided. Write
disconnected operation will fetch files from the server, but does not
propagate changes back immediately.
<P> An <B>-age</B> argument gives
the age of the CML before it should be reintegrated. The
<B>-time</B> arguments gives the number of seconds the sending of a
reintegration fragment should take. Abbreviation: <B>wd</B>
<P>
</DL>
<P>
<DL>
<DT><B><B>writereconnect</B></B><DD><P>Strongly connect to the
servers.
<P>Abbreviation: <B>wr</B>
<P>
</DL>
<P>
SEE ALSO
<H3></H3>
<P>chmod (1)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2s fs
<P>Maria R. Ebling, 1990, Created man page
<P>M. Satyanarayanan, 1992, cfs rewritten from scratch
<P>Joshua Raiff, 1993, Man page rewritten
<P>Joshua Raiff, 1995, Updated
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.2">19.2 clog(1) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>clog - Authenticate yourself to the Coda file system
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>clog</B> [[-x] user [ password ] ]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This command enables users to get tokens to use for authenticated
communication with a Coda File System. The given name
and password are passed to an <EM>Authentication Server</EM>. The
<EM>Authentication Server</EM> returns a set of tokens encoding the chosen
identity if the password is correct. <B>clog</B> passes these tokens to the
<EM>venus</EM> process, which acts as the users agent for file
manipulation. These tokens have a limited lifetime, becoming invalid after 25 hours. If an attempt is made to operate on a Coda File System object
while the user is not authenticated, the user will assume the privileges of the
<EM>Anonymous</EM> user.
<P><EM>clog</EM> accepts the following arguments:
<DL>
<DT><B><B>user</B></B><DD><P>Login name you wish to be identified as.
<P>
</DL>
<DL>
<DT><B><B>passwd</B></B><DD><P>Password corresponding to the
given user name. (If not provided on the command line, the user will be prompted for one.)
<P>
</DL>
<P>
<P>
BUGS
<H3></H3>
<P>The <B>-x</B> switch is not needed. Specifying a <EM>username</EM> and
<EM>passwd</EM> is sufficient.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>cunlog (1), venus (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2
<P>Maria R. Ebling, 1990, Created man page
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.3">19.3 cmon(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>cmon - Coda server monitor
<P>
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>cmon</B> [<B>-a</B>] [<B>-t</B> probeinterval] server1:hz1 server2:hz2 ......
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>cmon</B> probes the specified list of servers once every <EM>probeinterval</EM>
seconds and reports on their status. If a server is down or unreachable,
<B>cmon</B> tries to reestablish contact with it once every <EM>probeinterval</EM>
seconds. It uses the <EM>curses (3)</EM> package for screen management and
can be used on dumb terminals. Run <B>cmon</B> in a terminal emulator (like <EM>xterm</EM>) if you are using a window manager (like <EM>X</EM>).
<P><EM>Hz1, hz2,</EM> etc. are the values of the kernel constant <EM>HZ</EM> on the
respective servers. This constant is different for each machine type
and denotes the number of jiffies per second. Common values
are 64 (IBM-RT and DEC MIPS), 100 (Vax), and 50 (Sun3). This constant is needed to
convert CPU usage (reported in jiffies by servers) to seconds.
<P>Some <B>cmon</B> data can be displayed in relative or absolute modes. In
relative mode, data is reported with reference to the interval between the
last two probes. In absolute mode, the accumulated value since initialization
is reported. <B>cmon</B> can be toggled between absolute and real modes of
presentation from the keyboard. Typing <CODE>a</CODE> will cause data to be
presented in absolute mode. Typing <CODE>r</CODE> will present it in relative
mode. A mode change will only take place at the next probe.
<P>
<P>
<P>The command-line options are:
<DL>
<DT><B><B>-a</B></B><DD><P>Report data in absolute mode.
<P>
</DL>
<P>
<DL>
<DT><B><B>-t</B> probeinterval</B><DD><P>Probe servers every <EM>probeinterval</EM> seconds. Default is 60.
<P>
</DL>
<P>The data reported by <B>cmon</B> is organized under four headings: <EM>TIM,</EM>
<EM>CPU,</EM> <EM>RPC,</EM> and <EM>DSK.</EM>
<P>The <EM>TIM</EM> data is as follows:
<DL>
<DT><B><EM>mon</EM></B><DD><P>time at which this <B>cmon</B> process was created.
<P>
</DL>
<DL>
<DT><B><EM>prob</EM></B><DD><P>time at which the server was last probed.
<P>
</DL>
<DL>
<DT><B><EM>succ</EM></B><DD><P>time at which the server last responded to a probe.
<P>
</DL>
<DL>
<DT><B><EM>up</EM></B><DD><P>time at which the server process was started.
<P>
</DL>
<DL>
<DT><B><EM>bind</EM></B><DD><P>number of times contact was reestablished after a failed probe. A probe may fail due to server or network failures.
<P>
</DL>
<P>The <EM>CPU</EM> data is as follows:
<DL>
<DT><B><EM>sys</EM></B><DD><P>relative or absolute number of seconds of system CPU time used on the server.
<P>
</DL>
<DL>
<DT><B><EM>user</EM></B><DD><P>relative or absolute number of seconds of user CPU time (regular or niced) used on the server.
<P>
</DL>
<DL>
<DT><B><EM>util</EM></B><DD><P>relative or absolute number of system and user seconds divided by corresponding time of accumulation.
<P>
</DL>
<P>The <EM>RPC</EM> data is as follows:
<DL>
<DT><B><EM>conn</EM></B><DD><P>number of RPC connections.
<P>
</DL>
<DL>
<DT><B><EM>wkst</EM></B><DD><P>number of workstations connected to server. Note that each instance of <B>cmon</B> shows up as a workstation.
<P>
</DL>
<DL>
<DT><B><EM>call</EM></B><DD><P>relative or absolute number of RPC calls received.
<P>
</DL>
<DL>
<DT><B><EM>pki</EM></B><DD><P>relative or absolute number of RPC packets received. Includes duplicates and other bogus packets. Also includes bulk transfer packets.
<P>
</DL>
<DL>
<DT><B><EM>pko</EM></B><DD><P>relative or absolute number of packets sent. Includes retransmissions. Also includes bulk transfer packets.
<P>
</DL>
<DL>
<DT><B><EM>byi</EM></B><DD><P>bytes corresponding to <EM>pki.</EM>
<P>
</DL>
<DL>
<DT><B><EM>byo</EM></B><DD><P>bytes corresponding to <EM>pko.</EM>
<P>
</DL>
<P>The <EM>DSK</EM> data is as follows:
<DL>
<DT><B><EM>max1</EM></B><DD><P>identity and percent usage of most full disk partition on server. The identity is the name of mount point. Names longer than 5 characters are truncated to the first 3 characters, a $ character, and the last character.
<P>
</DL>
<DL>
<DT><B><EM>max2</EM></B><DD><P>identity and percent usage of second most full disk.
<P>
</DL>
<DL>
<DT><B><EM>max3</EM></B><DD><P>identity and percent usage of third most full disk.
<P>
</DL>
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>If a server is down or unreachable, statisitics for it are reported as "???".
<P>Relative data is undefined until two or more probes have been made. Such
data is reported as "***" between the very first and second probes.
<P>
<P>
<P>
BUGS
<H3></H3>
<P>Relative computations are just based on the difference between the two most
recent probes. A smarter approach (especially for CPU utilization) would
be to use some kind of weighted history.
<P>
<P>The display is optimized for maximum packing of information into a small
screen area. It may be cryptic for a novice.
<P>No disk information is available about the root partition on a server.
<P>Will core dump if run in a window with fewer than 25 lines.
<P>No way to force a redisplay (eg ^L).
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>vutil (8), curses (3), codacon (1)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>M. Satyanarayanan, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.4">19.4 cpasswd(1) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>cpasswd - change Coda login password
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>cpasswd</B> [-h host] [username]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This command sets the password associated with the current user, or user
<EM>username</EM> if explicitly named. Only the user or a System Administrator
may change a password.
<P><EM>cpasswd</EM> prompts for the users old password (or the password of the
administrator performing the change) and then for the new one. The new
password must be typed twice, to forestall mistakes. Change requests
can be aborted by typing a carriage return when prompted for the new password.
<P>New passwords must be at least four characters long if they use a sufficiently
rich alphabet and at least six characters long if monocase. These rules are
relaxed if you are insistent enough.
<P><EM>cpasswd</EM> wont be able to change the users password if the password server is down.
An appropriate error message will be printed, advising the caller to try again later.
Once the password server acknowledges receipt the users new password, it takes about
an hour for the information to propagate to the entire set of
<EM>AuthServers</EM>.
<P><B>cpasswd</B> support the following option:
<DL>
<DT><B><B>-h</B> <EM>host</EM></B><DD><P>Tells <B>cpasswd</B> which
authentication host to bind to. This should be the SCM.
<P>
</DL>
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/db/user.coda</EM>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>The password file information should be kept in a different data structure
allowing indexed access; <EM>dbm (3X)</EM> would probably be suitable.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>clog (1), crypt (3)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2
<P>Maria R. Ebling, 1990, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.5">19.5 ctokens(1) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>ctokens - list all tokens
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>ctokens</B>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The <B>ctokens</B> command enables users to query
<EM>Venus</EM> for information about the set of authentication tokens it
holds for the user.
The <B>ctoken</B> command prints out the ID of the current user and
whether or not the user is currently authenticated.
<P>
<P>
<P>
BUGS
<H3></H3>
<P>If authenticated as another user, <B>ctokens</B> will say that you own
the token.
<P>
<P>
SEE ALSO
<H3></H3>
<P>clog (1), login (1), su (1), cunlog (1)
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2s unlog
<P>David C. Steere, 1990, Created man page
<P>
<P>
\newpage
<H2><A NAME="ss19.6">19.6 cunlog(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>cunlog - Tell the Coda Venus to release authentication tokens
<P>
<P>
<P>
SYSNOPSIS
<H3></H3>
<P><B>cunlog</B>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This command enables a user to inform the Coda Cache Manager, <EM>Venus</EM>, to
release the authentication tokens for that user. Without these tokens, the user
will not be able to access or modify his or her protected files until he or
she re-authenticates by running <B>clog</B>.
<P>
<P>
SEE ALSO
<H3></H3>
<P>login (1), su (1), clog (1), ctokens (1)
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2s unlog
<P>David Steere, 1990, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.7">19.7 filcon(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>filcon - the RPC2 filter control utility.
<P>
SYNOPSIS
<H3></H3>
<P>
<P><B>filcon</B>
<P><B>filcon isolate -s </B>srv1 [srv2 ... ] <B>-c</B> clnt1 [clnt2 ....]
<P><B>filcon join -s </B>srv1 [srv2 ... ] <B>-c</B> clnt1 [clnt2 ....]
<P><B>filcon clear -s </B>srv1 [srv2 ... ] <B>-c</B> clnt1 [clnt2 ....]
<P><B>filcon partition -s </B>srv1 <B>-c clnt1 </B>
<P><B>filcon heal -h</B> hostname1 port1 <B>-h</B> hostname2 port2
<P><B>filcon oldpartition -h </B> hostname1 port1 <B>-h</B> hostname2 port2
<P><B>filcon slow -h</B> hostname1 port1 <B>-h</B> hostname2 port2
<P><B>filcon help</B>
<P>
DESCRIPTION
<H3></H3>
<P><B>filcon</B> mainpulates the failure filters installed by low level
RPC2 code. There are two basic modes of use, interactive and command
line mode. The command line version are good for almost all common
tasks but have less flexibility than the interactive version which
gives full control over the filters.
<P>The Coda failure emulation package consists of two pieces: a library
of routines (<EM>libfail</EM>) that is linked in with each client and
server, and a user interface program (<EM>filcon</EM>) that controls
the behavior of the linked-in libraries. These components allow a
wide range of failure scenarios to be emulated, including server
failure, network failure, asymmetric and non-transitive communication,
and lossy networks.
<P>At each client and server, every incoming and outgoing packet is
presented to the failure emulation package. Each packet is checked
against an ordered list of filters. The first filter whose address
matches the IP address on the packet (destination for <EM>send</EM>
filters, or source for <EM>receive</EM> filters) is used to determine
what action should be taken on the packet.
<P>A filter consists of three parts: a <EM>probability</EM>, a
<EM>predicate</EM>, and a <EM>delay.</EM> The probability specifies
what fraction of packets that match the predicate are allowed to pass
through unharmed. The <EM>delay</EM> may be used to delay packets in
order to simulate a slow connection to those machines matching the
filters address. The delay will apply regardless of the probability.
Filters may either apply to <EM>in</EM>coming (receive) packets or
<EM>out</EM>going (send) packets.
<P><EM>filcon</EM> enables a user to manipulate filters. There are two
modes of operating with filcon: short summary <B>command line</B>
commands, and <B>interactive use</B>. The interactive user interface
presented by <EM>filcon</EM> is based on the <EM>readline (3)</EM> and
Coda parsing libraries. A command with arguments can be issued in two
ways. If only the command name is typed, <EM>filcon</EM> will prompt
the user for the arguments. The command name may be uniquely
abbreviated. Alternatively, all the arguments to a command may be
given on the command line. If any arguments are missing, the command
will fail; there is no partial prompting. This feature is intended to
allow the user to produce command scripts.
<P>
INTERACTIVE USAGE
<H3></H3>
<P>
<P>Start this mode by typing <B>filcon</B>.
<P>The following commands are available.
<DL>
<DT><B><B>addclient</B> <EM>host port</EM></B><DD><P>Connects to a client at
IP port number <EM>port</EM> on the host named <EM>host</EM>. (For Coda clients and
servers, use 1363 and 1361 respectively.)
<P>
</DL>
<P>
<DL>
<DT><B><B>deleteclient</B> <EM>clientnum</EM></B><DD><P>Disconnects from;
client number <EM>clientnum</EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>listclients</B></B><DD><P>Lists the current set of connected
clients.
<P>
</DL>
<P>
<DL>
<DT><B><B>insertfilter</B>
<EM>clientnum side id host color lenmin lenmax probability speed</EM></B><DD><P>Inserts a filter into client number <EM>clientnum</EM>'s table on the
specified <EM>side</EM> (one of <EM>in out</EM>). The filter will be
inserted after the existing filter with identifier <EM>id</EM>. (Inserting
after the filter with identifier <EM>0</EM> will insert the filter before all
existing filters.) The characteristics of the new filter are <EM>host, color,
lenmin, lenmax, probability</EM> and <EM>speed.</EM> <EM>Host</EM> is
specified as a name or an IP address of the form "a.b.c.d." Any of the 4 IP
components can be wildcarded by specifying a value of -1. Thus "-1.-1.-1.-1"
matches any host, while "128.2.-1.-1" matches any host on subnet 2 at CMU.
<EM>Lenmin</EM> and <EM>lenmax</EM> specify the minimum and maximum RPC
packet sizes that match this filter. <EM>Color</EM> is a number in the range
from 0 to 254. A value of -1 specifies that any color matches. RPC2
connections can be colored using the call RPC2_SetColor (). Packets
sent out on a connection acquire the color of the connection. Note that
reply packets acquire the color of the reply connection, which may be
different. Colors are particularly valuable in stressing critical phases of
higher-level protocols. By changing connection color between phases, one can
easily investigate the effect of failures on specific phases. Probability is
specified as an integer in the range from 0 to 10000, and correspond to
floating point numbers in the range 0.00 to 1.00. The speed is the speed in
bits per second that data should be transmitted between the machines. The
value returned from this routine is the filters unique identifier. Speeds
other than the default cannot be applied on <EM>receive</EM> filters.
<P>
</DL>
<P>
<DL>
<DT><B><B>removefilter</B> <EM>clientnum side id</EM></B><DD><P>Removes the filter
with identifier <EM>id</EM> on the given side of client <EM>clientnum.</EM>
<P>
</DL>
<P>
<DL>
<DT><B><B>getfilters</B> <EM>clientnum</EM></B><DD><P>Lists the filters at client
<EM>clientnum.</EM>
<P>
</DL>
<P>
<DL>
<DT><B><B>purgeFilters</B> <EM>clientnum</EM> <EM>side</EM></B><DD><P>Removes all
filters from the set specified by <EM>side</EM>. <EM>side</EM> can be either
<EM>in</EM>, <EM>out</EM>, or <EM>both</EM> (the default).
<P>
</DL>
<P>
<DL>
<DT><B><B>quit</B></B><DD><P>Terminates the program. Note that this does
not clear any filters.
<P>
</DL>
<P>
COMMANDLINE INVOCATIONS
<H3></H3>
<P>
<P>
<DL>
<DT><B><B>filcon isolate</B></B><DD><P>isolate the servers and clients
from all other Coda servers and clients. Servers will still listen to
themselves allowing for system administration to proceed on the
machine.
<P>
<DT><B><B>filcon join</B></B><DD><P>This is normally issued after isolate and inserts a
matrix of filters to allow communication between the clients and
servers listed on the command line.
<P>
<DT><B><B>filcon clear</B></B><DD><P>Removes all filter from the hosts given.
<P>
<DT><B><B>partition</B></B><DD><P>blocks traffice between the hosts given.
<P>
<DT><B><B>heal</B></B><DD><P>removes all of the filters between <EM>hostname1</EM> and <EM>hostname2</EM> inserted by partition, or slow, or filcon.
<P>
<DT><B><B>slow</B></B><DD><P>inserts filters on <EM>hostname1</EM> and <EM>hostname2</EM> to control the
network speed between the machines.
</DL>
<P>
ARGUMENTS
<H3></H3>
<P>
<P>
<DL>
<DT><B><B>port</B></B><DD><P>Port to attatch to. This should be 1363 for a
Coda client and 1361 for a server.
<DT><B><B>speed</B></B><DD><P>Speed in bits per second
</DL>
<P>
BUGS
<H3></H3>
<P>You cannot currently designate a host by IP address of the form
a.b.c.d as described above when binding to a process.
<P>May confuse the user with the error message ``RPC2_SUCCESS.''
<P>No authentication or security checks are done. Denial of service
attacks are trivial, since any user can set up
filters on any other client or server.
<P>
<P>
AUTHOR
<H3></H3>
<P>Walter Smith, 1988, created.
M. Satyanarayanan, 1990, updated.
Puneet Kumar, 1990, Created
Maria R. Ebling, 1991, updated.
Lily Mummert, 1992, Added support for <EM>speed</EM>.
David Steere, 1994, Added "purgeFilters", slight rewrite.
Joshua Raiff, 1993, Created man page
<P>Peter Braam, 1998, Complete rewrite for filcon.
<P>
\newpage
<H2><A NAME="ss19.8">19.8 hoard(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P> hoard - hoard database front-end
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>hoard</B> [ -d ] [ -f source | cmds ]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>Hoard</B> is a front-end to the <EM>hoard database</EM> (HDB) managed by the Coda
cache manager, <EM>Venus</EM>. The HDB provides a means for users to explicitly
control Venus caching behavior. HDB entries specify the degree of a users
interest in particular file system objects. Venus combines this information
with implicit knowledge that it has about file access patterns to try to
keep the "best" set of objects in its cache at all times. The HDB is
maintained in non-volatile storage, so it survives Venus restarts and client
reboots.
<P>Users manipulate the HDB by issuing commands to the hoard program.
The following hoard commands are currently recognized:
<DL>
<DT><B><B>add</B> filename <attributes></B><DD><P>
</DL>
<DL>
<DT><B><B>clear</B> <uid></B><DD><P>
</DL>
<DL>
<DT><B><B>delete</B> filename</B><DD><P>
</DL>
<DL>
<DT><B><B>list</B> outfile <uid></B><DD><P>
</DL>
<DL>
<DT><B><B>modify</B> filename <attributes></B><DD><P>
</DL>
<P>Hoard distinguishes between <EM>children</EM> of a directory, which are
members of the directory, <EM>descendants</EM> which are either children
or descendants of childres of the directory.
<P>Commands may be abbreviated by their first letter. Parameters in angle
brackets are optional, and have default values if unspecified. The
<EM>attributes</EM> parameter is specified as a string of options separated by
: characters. The currently recognized options are:
<DL>
<DT><B><B>1-1000</B></B><DD><P>assign this object the hoard <EM>priority</EM>
indicated
<P>
</DL>
<DL>
<DT><B><B>c</B></B><DD><P>current <EM>children</EM> of this directory will inherit its
hoard status
<P>
</DL>
<DL>
<DT><B><B>c+</B></B><DD><P>current and future <EM>children</EM> of this directory will
inherit its hoard status
<P>
</DL>
<DL>
<DT><B><B>d</B></B><DD><P>current <EM>descendents</EM> of this directory will inherit
its hoard status
<P>
</DL>
<DL>
<DT><B><B>d+</B></B><DD><P>current and future <EM>descendents</EM> of this directory
will inherit its hoard status
<P>
</DL>
<P>If the <EM>uid</EM> in the clear and list commands is unspecified, the entries of
all users are cleared or listed respectively. The default hoard
<EM>priority</EM> is 10.
<P>An example command file is:
<DL>
<DT><B><B>clear</B></B><DD><P>
</DL>
<DL>
<DT><B><B>add</B> /coda/project/coda/src 100:d+</B><DD><P>
</DL>
<DL>
<DT><B><B>add</B> /coda/usr/jjk/.login 1000</B><DD><P>
</DL>
<P>
<P>Access to the hoard database is restricted in the following ways. All hoard
commands fail unless the effective-uid is root--the hoard program should be
made setuid to root to ensure this. Special permission is given to commands
where the real-uid is root or that of the <EM>primary</EM> user, i.e., the user
at the console. Root and primary users may add entries and access existing
entries without restriction. Other users may not add hoard entries, and
they may only clear, delete, list, or modify their own entries.
<P>The command-line options are:
<DL>
<DT><B><B>-d</B></B><DD><P>Enables debugging output.
<P>
</DL>
<DL>
<DT><B><B>-f</B> <EM>source</EM></B><DD><P>Take commands from file <EM>source</EM>.
-f must be the last argument if specified. An argument of - means use
<B>stdin</B> as the source file. Source statements may be given directly on
the command line (one per line) by enclosing them in single quotes.
<P>
</DL>
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>Hoard copies command lines that it cannot parse to <B>stderr</B>.
If a syntactically correct command is rejected by Venus, the corresponding pioctl, its arguments, and the errno are copied to <B>stderr</B>.
<P>
<P>
<P>
BUGS
<H3></H3>
<P>Negative priorities should be allowed.
<P>A mount point of <EM>/coda</EM> is assumed by the pioctl library.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>venus (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.9">19.9 mvdb(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>mvdb - Atomically update files in a directory
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>mvdb</B> [-l lockfile] file1 file2 ...
<P>or
<P><B>mvdb</B> [-l lockfile] newfile1=file1 newfile2=file2 .....
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>mvdb</B> is used to lock a directory exclusively and then atomically
update a set of files in it. A file is moved in only if it does not already
exist in the current directory, or if the version in this directory is older.
You must be <CODE>cd</CODE>'d into the destination directory already. If you do
not specify a <EM>lockfile</EM>, the current directory "." is locked. The
Unix primitive <EM>flock</EM>() is used for locking. For each file moved in,
you can choose to retain
the original name or give it a new name by using the <EM>newfile=file</EM> construct. If a file
<EM>filename</EM> already exists in the directory, it is first renamed to <EM>filename.BAK</EM>.
The dates of the target are copied from the source files.
<P>The options are:
<P>
<DL>
<DT><B><B>-v</B></B><DD><P>Verbose mode. Will print out information on the progress of the command.
<P>
</DL>
<DL>
<DT><B><B>-u</B></B><DD><P>Force update. Moves in the files even if the source files are not newer.
<P>
</DL>
<P>
<P>
EXAMPLE
<H3></H3>
<P>
<BLOCKQUOTE><CODE>
<PRE>
cd /itcbin/vice/bin
mvdb /usr/andrew/bin venus2.sun=venus2 file salvage
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>All the files have to come from the same source directory.
<P>You have to be <CODE>cd</CODE>'d into the target directory.
You need Lock rights in Vice directories for locking.
<P>
<P>
AUTHOR
<H3></H3>
<P>Created: M.Satyanarayanan, 1985
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.10">19.10 repair(1) </A>
</H2>
<P>
NAME
<H3></H3>
<P>repair - repair conflicts in the Coda file system
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>repair</B> [-d]
<P><B>repair</B> [-allowclear]
<P><B>repair</B> [<object_in_conflict> <fix_file> <repair_options>]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The Coda repair tool allows you to manually
resolve two kinds of conflict resulted from partitioned updates.
Server-server conflicts are conflicting mutations performed on
partitioned servers that can not be automatically resolved.
Local-global conflicts are caused by mutations performed on a
disconnected client that are in conflict with the global server state.
<P><B>Repair</B> uses the <EM>ci</EM> command interpreter to present its user
interface or <CODE>repair</CODE> commands may be invoked from the command line.
Several instructions may appear on a single line separated
by semicolons. You can abbreviate command, variable, and help topic
names. To send output into a file, end the command line with
> filename.
<P>To use the repair tool interactively, type <B>repair</B> at the command
prompt.
<P>Server-Server conflicts can be repaired from the command line without
entering interactive mode. This is useful if you need to repair many
conflicts within a volume at a time and wish to write a shell script.
Please see the <B>EXAMPLES</B> section for examples on
invoking complete repair sequences from the command line.
<P>A description of the <B>repair</B> command follows:
<P>
<DL>
<DT><B><B>beginrepair</B> <EM>object</EM></B><DD><P>verifies that
<EM>object</EM> is indeed in conflict. It will print out messages to
indicate whether the current repair session is for server-server
conflict or local-global conflict.
<P> For a server-server repair
session, this command locks the corresponding volume and and mounts
its individual replicas read-only. It will inform the users to only
use the <B>comparedirs</B>, <B>dorepair</B> and <B>removeinc</B>
commands to repair the conflict.
<P> For a local-global repair session,
both local
and global replicas of <EM>object</EM> are visible at
<EM>object/local</EM> (read-only) and <EM>object/global</EM>
(mutable and serving
as the workspace for storing the repair result for <EM>object</EM>). You
need to iterate through the current sessions <EM>local-mutations-list</EM>
containing all the local updates to <EM>object</EM> and its descendants.
Each operation in <EM>local-mutations-list</EM> must be accounted for and
Venus maintains the <EM>current-mutation</EM> being iterated. Use the
<B>checklocal</B> command to find out the conflict between the
<EM>current-mutation</EM> and the server state. Note that not all local
mutations are necessarily in conflict, and you can use the
<B>listlocal</B> command to see all the operations in
<EM>local-mutations-list</EM>. You can advance the iteration to the next
operation using either the <B>preservelocal</B> or the <B>discardlocal</B>
command with the former replaying the <EM>current-mutation</EM> operation
on the relevant global replicas. To speed up the iteration, the
<B>preservealllocal</B> command repeats <B>preservelocal</B> until the
<EM>local-mutations-list</EM> is exhausted or the first replay failure.
Similarly, the <B>discardalllocal</B> command repeats <B>discardlocal</B>
until exhausting the <EM>local-mutations-list</EM>. You can use external
tools such as <EM>emacs</EM> to make direct updates on needed replicas under
<EM>object/global</EM>. Use the <B>quit</B> command to either commit or abort
the session.
<P>
</DL>
<P>
<DL>
<DT><B><B>quit</B></B><DD><P>If the current session is repairing a
server-server conflict, this command releases all the volume-level
locks and causes the repair tool to return to the shell. If the
current session is repairing a local-global conflict, this command
asks you whether to commit or abort the repair session. If you answer
yes, the mutations performed on the relevant global replicas will be
committed to the servers. Otherwise, the repair result will be aborted
as if this repair session has never happened.
<P>
</DL>
<P>
<DL>
<DT><B><B>help</B></B><DD><P>prints out a help message.
<P>
</DL>
<P>Use the following commands to repair a server-server conflict:
<P>
<DL>
<DT><B><B>comparedirs</B> <EM>object</EM> <EM>fixfile</EM>
<EM>[-acl <user> <rwlikda > ]</EM>
<EM>[-mode <newmode> ]</EM>
<EM>[-owner <username> ]</EM></B><DD><P>compares
the mounted read-only replicas of a directory in conflict and prints
the repair commands in fixfile to make the replicas identical. To
print out the repair commands on your terminal give stdout as the
pathname for fixfile. Compensating actions for Name/Name conflicts and
Update/Update conflicts are not given. The user is only told about
their existence and required to edit the fixfile manually. You should
have already done a <B>beginrepair</B> on <EM>object</EM> and this command
works only if <EM>object</EM> is a directory.
<P>
</DL>
<P>
<DL>
<DT><B><B>dorepair</B> <EM>object</EM> <EM>fixfile</EM></B><DD><P>does the actual
repair of an object. If the repair succeeds, each accessible replica will
be marked consistent. You will be prompted for the arguments if they are
missing, and will be asked to confirm the repair. You should have already
done a <B>beginrepair</B> on this object (or on on some other object in
this volume.). If <EM>object</EM> is a file or symbolic link,
<EM>fixfile</EM> must provide its new contents. If <EM>object</EM> is a
directory, <EM>fixfile</EM> must provide a sequence of directory repair
commands for each replica. The format of fixfile for directories is as
follows:
<P>
</DL>
<BLOCKQUOTE><CODE>
<PRE>
replica <servername> <id of replica1>
<repair commands for replica1>
replica <servername> <id of replica2>
<repair commands for replica2>
and so on
</PRE>
</CODE></BLOCKQUOTE>
Repair commands are given one per line. Blank lines are ok. <EM>id of
replica1</EM>, <EM>id of replica2</EM>, etc. are numbers that identify
each replica. These are the same as the volume ids of read-write volumes
corresponding to a replicated volume. The volume ids can be obtained by
doing an ls on the inconsistent object, after the <B>beginrepair</B>
command has succeeded. The directory repair commands are:
<BLOCKQUOTE><CODE>
<PRE>
createf <filename> <fid.0> <fid.1> <fid.2>
creates <symlinkname> <fid.0> <fid.1> <fid.2>
createl <linkname> <fid.0> <fid.1> <fid.2>
created <dirname> <fid.0> <fid.1> <fid.2>
removefsl <filename or symlinkname or linkname>
removed <dirname>
mv <srcname> <tgtname> <src <fid.0><fid.1><fid.2>>
<target <fid.1> <fid.2>>
setacl <username> [rwlikda]
delacl <username>
setmode <newmode>
setowner <new owner name>
setmtime <new modified time>
</PRE>
</CODE></BLOCKQUOTE>
Note that for the <B>setacl</B> command, the short form
access rights of <B>all</B> and <B>none</B> can also be used.
<P>
<DL>
<DT><B><B>removeinc</B> <EM>object</EM></B><DD><P>removes the
inconsistent <EM>object</EM> if it is file or a symbolic link. If the
object is a directory, all the descendants of the object will be
removed in all the accessible replicas and the directory itself will
be removed as long as its replicas are identical. If the owner or the
ACL of the directory replicas are different, you have to repair the
conflict first.
<P>
</DL>
<DL>
<DT><B><B>clearinc</B> <EM>object</EM></B><DD><P>compares the mounted
read only replicas of a directory in conflict and if the replicas are
identical it clears the inconsistency flag of the replicas. Otherwise
it will inform you about the inequality of the replicas. You should
run the <B>comparedirs</B> command to find out the cause of conflict.
This command should be used only for directories. Files and symbolic
links are cleared of their inconsistency with the <B>dorepair</B>
command.
<P>
</DL>
<P>The following commands are used only for repairing local-global
conflicts:
<P>
<DL>
<DT><B><B>checklocal</B></B><DD><P>checks to see if the
<EM>current-mutation</EM> being iterated by the current local-global repair
session is in conflict with the server state. It displays the operator
and operand (s) of the <EM>current-mutation</EM> operation and indicates
whether it is in conflict with the relevant server replicas. If it is
in conflict, a brief reason of the conflict is given. Note that this
command does not advance the iteration of the
<EM>local-mutations-list</EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>discardlocal</B></B><DD><P>simply advances the iteration
of the <EM>local-mutations-list</EM> of the current local-global repair
session to the next operation. Use this command when the user does not
want the <EM>current-mutation</EM> operation to have any effect on the
repair result.
<P>
</DL>
<P>
<DL>
<DT><B><B>preservelocal</B></B><DD><P>tries to replay the
<EM>current-mutation</EM> of the current local-global repair session on the
relevant global replicas. In other words, it will try to preserve the effect
of the <EM>current mutation</EM> in the repair result. If the replay
succeeds, the iteration of <EM>local-mutations-list</EM> will be advanced to
the next operation. The effect of the replay is visible only on this client
and not on the server until the repair result is successfully committed. If
the replay fails, information about the reason of the failure will be
displayed.
<P>
</DL>
<P>
<DL>
<DT><B><B>discardalllocal</B></B><DD><P>repeatedly performs the
<B>discardlocal</B> command until the <EM>local-mutations-list</EM> is
exhausted. Its effect is to finish the iteration and discard the
effect of all the remaining mutations on the repair result.
<P>
</DL>
<P>
<DL>
<DT><B><B>preservealllocal</B></B><DD><P>repeatedly performs the
<B>preservelocal</B> command until the first failure or the iteration of
<EM>local-mutations-list</EM> is exhausted. This command is used if the
user wants to preserve the effect of all the remaining mutation
operations in the repair result.
<P>
</DL>
<P>
<DL>
<DT><B><B>listlocal</B></B><DD><P>prints out all the mutation
operations in the <EM>local-mutations-list</EM> of the current local-global
repair session.
<P>
</DL>
<P>
<DL>
<DT><B><B>setglobalview</B></B><DD><P>If the current local-global
repair session is repairing a conflict on <EM>object</EM> given as the
argument to the <B>beginrepair</B> command, the global replica of
<EM>object</EM> is visible at <EM>object/global</EM>. This command allows the
global replica of <EM>object</EM> to be visible at the original
location (pathname) of <EM>object</EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>setlocalview</B></B><DD><P>If the current local-global
repair session is repairing a conflict on <EM>object</EM> given as the
argument to the <B>beginrepair</B> command, the local replica of
<EM>object</EM> is visible at <EM>object/local</EM>. This command allows the
local replica of <EM>object</EM> to be visible at the original
location (pathname) of <EM>object</EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>setmixedview</B></B><DD><P>If the current local-global
repair session is repairing a conflict on <EM>object</EM> given as the
argument to the <B>beginrepair</B> command, this command restore the
default form of local-global conflict representation in which the
local replica is visible at <EM>object/local</EM> and the global replica is
visible at <EM>object/global</EM>.
<P>
</DL>
<P>The following commands existed in old versions but are no longer
supported:
<P>
<DL>
<DT><B><B>showreplicas</B> <EM>object</EM></B><DD><P>shows the names of
the individual replicas of <EM>object</EM>, and the pathnames by which
these replicas may be examined read-only. A <B>beginrepair</B> must have
been done earlier on this object (or on another object in the same
volume).
<P>
</DL>
<P>
<P>
<DL>
<DT><B><B>unlockvolume</B> <EM>pathname</EM></B><DD><P>tells Venus to unlock
the specified volume in repair. No check is done to see if you locked
the volume during this repair session. The primary use of this command is
to unlock volumes that were locked during a previous, aborted, invocation
of the repair tool. The command will fail if Venus discovers that you
do not hold the repair lock on the server. This could happen, for
example, if your aborted repair occurred on another workstation, or if
you were not repairing the volume in the first place.
<P>
</DL>
<P>
EXAMPLES
<H3></H3>
<P>
<P>This will cause repair to examine the object "<CODE>common</CODE>",
generate a fix file for it and in addition to the contents of the
fix file, set the acl's for hmpierce on all of the replica.
<P>
<BLOCKQUOTE><CODE>
<PRE>
repair common /tmp/fix -acl hmpierce all
</PRE>
</CODE></BLOCKQUOTE>
<P>The same repair would look like this in interactive mode:
<BLOCKQUOTE><CODE>
<PRE>
repair> beginrepair common
repair> comparedirs common /tmp/fix -acl hmpierce all
repair> dorepair common /tmp/fix
repair> endrepair
repair> quit
</PRE>
</CODE></BLOCKQUOTE>
<P>
SEE ALSO
<H3></H3>
<P>ci (3)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>M. Satyanarayanan, 1989, Created
<P>Puneet Kumar, 1991, Substantially revised
<P>Joshua Raiff, 1993, Created man page
<P>Qi Lu, 1995, Added local-global repair commands and revised man page
<P>Henry M. Pierce, 1998, updated for command line options.
<P>
\newpage
<H2><A NAME="ss19.11">19.11 spy(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>spy - Report all CFS files that are opened
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>spy</B> [ -host <hostname> ] [ -uid <uid> ]
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>spy</B> will connect to <EM>venus</EM> on the given host and report all Coda
files that are opened. This is useful for generating <EM>hoard</EM> files
as programs can have hidden dependencies. Using spy will ensure that
any file that is opened gets included in the <EM>hoard</EM> database.
Sending <B>spy</B> a <EM>SIGTERM</EM> will cause <B>spy</B> to flush all of its
output buffers and terminate.
<P><B>spy</B> supports the following options:
<P>
<DL>
<DT><B><B>-host</B> <EM>hostname</EM></B><DD><P>Name of Coda coda client
to bind to. If this option is omitted, then the current host will be
used.
<P>
</DL>
<P>
<DL>
<DT><B><B>-uid</B> <EM>uid</EM></B><DD><P>Only report on file activity
from user <EM>uid</EM>. If the <B>-uid</B> switch is omitted, then all CFS
file activity is reported.
<P>
</DL>
<P>To use <B>spy</B> to create a <EM>hoard</EM> file sort the output and remove
any duplicates, By using <B>spy</B> you ensure that you did not forget to
<EM>hoard</EM> a file with a hidden
dependency. For example, when you <EM>hoard X</EM>, you will need the
<EM>uncompress (1)</EM> program in order to use the fonts.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>hoard (1)
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1993, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.12">19.12 venussetup(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P> <B>venus-setup</B> setup <B>venus</B> on a client
<P>
SYNOPSIS
<H3></H3>
<P><B>venus-setup</B> [comma,separated,list,of,servers] [cachesize in kb]
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The <B>venus-setup</B> command takes a list of servers separated
by commas, one of which must be the SCM and a cache size given in
kilobytes. <EM>NOTE</EM>: at least one server must be specified. And
if only one server is specified, it must be the SCM for the Coda Cell.
<B>Venus-setup</B> then performs the following operations:
<UL>
<LI>Creates the <EM>/coda</EM> mount point if not present.</LI>
<LI>Creates <EM>/usr/coda</EM> if not present.</LI>
<LI>Creates necessary subdirectories under <EM>/usr/coda</EM> if not present.</LI>
<LI>Creates <EM>/usr/coda/etc/vstab</EM> with parameters given on the
command line.</LI>
<LI>Creates <EM>/dev/cfs0</EM> if not already present.</LI>
<LI>Adds Coda filesystem port numbers to <EM>/etc/servers</EM> if not present.</LI>
</UL>
<P>
EXAMPLE
<H3></H3>
<P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
Venus-setup Mickey,Minnie,Goofy 10000
</PRE>
</CODE></BLOCKQUOTE>
Sets up, <EM>/usr/coda/etc/vstab</EM>, for <B>venus</B> to
contact either Mickey, Minnie or Goofy and configures venus with a 10MB
cache.
<P>
BUGS
<H3></H3>
<P>The [cachesize in kb] option to venus-setup is not very smart. In
fact, it is quite dumb. No abbreviations are allowed after the
number and the number is taken literally to be kilobytes.
<P><B>Venus-setup</B> will happily overwrite an existing,
<EM>/usr/coda/etc/vstab</EM>, without warning.
<P>
FILES
<H3></H3>
<P><EM>/etc/services</EM>: the Internet network services list.
<EM>/usr/coda/etc/vstab</EM>: the VenuS TABle specification file.
<P>
SEE ALSO
<H3></H3>
<P>venus (8), vstab (5), services (5), servers (5)
<P>
Coda Manual: ``Installing A Coda Client''
<P>
<P>
AUTHOR
<H3></H3>
<P>Henry M. Pierce, 1998, created
<P>
\newpage
<H2><A NAME="ss19.13">19.13 vicesetup(1) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P> <B>Vice-setup</B> setup a Coda server
<P>
SYNOPSIS
<H3></H3>
<P><B>Vice-setup</B>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>Vice-setup</B> is the user front-end to a family of scripts designed
to setup a Coda server based on question-answer responses. This avoids
an otherwise tedious and error-prone-manual method. The most critical
question asked for the vice-setup family of scripts to work
properly is:
<P>
<BLOCKQUOTE><CODE>
<PRE>
Is this the master server, aka the SCM machine? (y/n)
</PRE>
</CODE></BLOCKQUOTE>
<P>Answering ``yes'' to this question causes the following
sequence of scripts to be called from within <B>vice-setup</B>:
<P>
<UL>
<LI><B>vice-setup-scm</B></LI>
<LI><B>vice-setup-user</B></LI>
<LI><B>vice-setup-rvm</B></LI>
<LI><B>vice-setup-srvdir</B></LI>
</UL>
<P>where as answering ``no'' causes only the following scripts to run
from <B>vice-setup</B>:
<P>
<UL>
<LI><B>vice-setup-rvm</B></LI>
<LI><B>vice-setup-srvdir</B></LI>
</UL>
<P>
<P>
OVERVIEW
<H3></H3>
<P>
<DL>
<P>
<DT><B><B>Vice-setup</B></B><DD><P>is designed to be called directly by
the administrator to setup a server. It performs the
following tasks common to both SCM and non-SCM servers:
<P>
<UL>
<LI>Creates the directories, <EM>/vice,/vice/{backup,db,srv,vol}</EM>
and, <EM>/vice/vol/remote</EM> if they do not already exist.</LI>
<LI>Creates and sets up the authentication files needed for interserver
and interclient communication.</LI>
<LI>Creates and sets up, <EM>/vice/db/files</EM>, which are a set of common
Coda files distributed from the SCM via, <B>updateclnt</B>, and
<B>updatesrv</B>.</LI>
<LI>Adds Coda port numbers to, <EM>/etc/services</EM> if not already
present.</LI>
<LI>Sets up the Coda server to start at system startup if so indicated.</LI>
<LI>Records the hostname in, <EM>/vice/hostname</EM>.
</LI>
</UL>
<P>
<DT><B><B>Vice-setup-scm</B></B><DD><P>This script is only run if ``yes'' is given as an answer to the SCM question.
<P>
<UL>
<LI>Prompts for a Coda server ID in the range of 0-255,
and creates the file, <EM>/vice/db/servers</EM>, with this information.</LI>
<LI>Creates, <EM>/vice/db/scm</EM>, with the hostname of the SCM machine
being setup.</LI>
<LI>Creates, <EM>/vice/db/VSGDB</EM>, with the root volume number
``E0000100''.</LI>
<LI>Prompts for the name of the root volume and stores this information in,
<EM>/vice/db/ROOTVOLUME</EM>.
</LI>
</UL>
<P>
<DT><B><B>Vice-setup-user</B></B><DD><P>This script is only run by, <B>vice-setup</B>, when the machine
is designated as the SCM.
<UL>
<LI>This sets up the System:Administrator group and Coda user
``admin'' then initializes, <EM>/vice/db/vice.pdb</EM>.</LI>
<LI>Creates, <EM>/vice/db/passwd.coda</EM>, needed to setup the
initial password system.</LI>
<LI>Creates, <EM>/vice/db/auth.pw</EM>.</LI>
</UL>
<DT><B><B>Vice-setup-rvm</B></B><DD><P>
<UL>
<LI> Prompts for the RVM_LOG device.</LI>
<LI> Prompts for the size of the RVM_LOG device.</LI>
<LI> Prompts for the RVM_DATA device.</LI>
<LI> Prompts for the RVM_DATA size based on default values.
These values must be typed exactly right to be accepted. For example,
22M must be typed exactly as, "22M".</LI>
<LI> Initializes the RVM_LOG and RVM_DATA devices
based on the values given for RVM initialization.</LI>
<LI> Creates, /vice/srv.conf, with the values given for RVM.</LI>
</UL>
<DT><B><B>Vice-setup-srvdir</B></B><DD><P>This script sets up the data storage area for a Coda service.
<UL>
<LI> Prompts for the location a data storage area (default
is, /vicepa).</LI>
<LI> Creates the empty file, <EM>/vicepa/FTREEDB</EM>, which must exist in order for,
<B>makeftree</B>, to function.</LI>
<LI> Creates, <EM>/vice/db/vicetab</EM>.</LI>
<LI> Initializes the data storage area with, <B>makeftree</B>.</LI>
</UL>
<P>
</DL>
<P>For a detailed explanation of each question asked by the scripts,
please see the chapter, ``Installing a Coda Server'' in the Coda Manual.
<P>
BUGS
<H3></H3>
<P>Many of the highlights are:
<UL>
<LI><B>Vice-setup-scm</B>: does not actually create the ROOTVOLUME
it prompts for. It only sets up the accounting files that point the
server(s) to the root volume. The actual volume must be created
after the server is started for the first time with, <B>createvol_rep</B>.</LI>
<LI><B>Vice-setup-rvm</B>: will not warn you if run a second time after
setting up an otherwise working server. This essentially causes all
data stored on the Coda server in question to be wiped out.
</LI>
<LI><B>Vice-setup-user</B>: there is no flexibility in
setting up an administrative user called anything other than
``admin''.
</LI>
<LI><B>Vice-setup-user</B>: there is a security hole in,
<B>initpw</B>, that could allow unauthorized Coda ``admin''
access and/or denial of service if an unauthorized user gains
root access to the SCM.
</LI>
<LI><B>Vice-setup-user</B>: a user ``admin'' with a uid of 500
must exist on each client that needs to have admin access to
Coda. There is no practical way to test for this. The hardcoding
of uid 500 may cause additional trouble at some sites.
</LI>
<LI><B>Vice-setup-rvm</B>: will add entries to, <EM>/vice/srv.conf</EM>,
each time it is run without removing the previous contents. If more than
one line of server information is present in, <EM>srv.conf</EM>, a
``multiple instance error'' is returned by, <B>srv</B>, because multiple
lines in, <EM>srv.conf</EM>, are treated as a single set of command line
arguments to <B>srv</B>. Essentially, the resulting error is made
sufficiently out of context and is difficult to detect.
</LI>
<LI><B>Vice-setup</B>: does not determine the host IP address.
</LI>
<LI>Error messages returned by the scripts or the programs called
from within the scripts do not jump out and bark at you. Instead,
errors are easily missed while running the scripts and these errors
tend to come back and bite you later.
</LI>
<LI>If a non-SCM server is being setup, you still must respond
with tokens to, <B>vice-setup</B>, when asked. However, the
response must be identical to the SCM or the ticket files must be copied
from the SCM manually for interserver communication to work correctly.
</LI>
<LI><B>auth2</B>, <B>updateclnt</B> and <B>updatesrv</B> must be
started manually on a non-SCM to suck down the real versions of these files
from the actual SCM. This error in logic can be misleading.
</LI>
<LI>On non-SCM Servers, the following files on the SCM must be
edited or copied from the SCM manually before running:
<B>vice-setup</B>:<P><EM>/vice/db/services</EM>
<P><EM>/vice/db/hosts</EM>
<P>to complete the setup of a non-SCM server.
<P>
</LI>
</UL>
<P>
FILES
<H3></H3>
<P><EM>/vice/db/vicetab</EM>: the Vice Table Configuration file for srv.
<P><EM>/vice/vol/VolumeList</EM>: volumeList of the server.
<P><EM>/vice/db/scm</EM>: the SCM hostname.
<P><EM>/vice/hostname</EM>: the host's hostname.
<P><EM>/vice/srv.conf</EM>: the <B>srv</B> configuration file.
<P><EM>/vice/db/services</EM>
<P><EM>/vice/db/ROOTVOLUME</EM>
<P><EM>/vice/db/VSGDB</EM>
<P><EM>/vice/db/vice.pfc</EM>
<P><EM>/vice/db/vice.pdb</EM>
<P>
<P>And many more files are touched by these scripts than are listed here.
<P>
SEE ALSO
<H3></H3>
<P>srv (8), rvmutl (8), rdsinit (8), auth2 (8), authmom (8), updatemon (8),
updatesrv (8), updateclnt (8), startserver (8), srv.conf (8), createvol_rep (8),
pwd2pdb (8), initpw (8), makeftree (8), vicetab (5)
<P>
<P>
Coda Manual: ``Installing A Coda Server''
<P>The RVM Manual
<P>
<P>
AUTHOR
<H3></H3>
<P>Henry M. Pierce, 1998, created
<P>
\newpage
<H2><A NAME="ss19.14">19.14 volmunge(1) </A>
</H2>
<P>
NAME
<B>volmunge</B> - manipulates objects within Coda.
<H3></H3>
SYNOPSIS
<B>volmunge</B> <-adfmov> dir
<H3></H3>
<P>
<P>
<DL>
<P>
<DT><B><B>-a</B></B><DD><P>Prints out everything but does not cross volume boundaries.
<DT><B><B>-d</B></B><DD><P>Prints out UNIX directories, but not volume mount points.
<DT><B><B>-f</B></B><DD><P>Prints out all objects which are not volume mount points (eg
UNIX files and UNIX directories); this preforms a stat()
call on all non-volume objects which is ideal for forcing resolution
on a volume.
<DT><B><B>-m</B></B><DD><P>Prints out those objects which are volume mount points.
<DT><B><B>-o</B></B><DD><P>Prints out those objects which are UNIX files and preforms an open() call
on the file.
<DT><B><B>-v</B></B><DD><P>Prints out the volume name of a volume's mount point.
</DL>
<P>
DESCRIPTION
<H3></H3>
<P>
<P><B>volmunge</B>: is ideal for identifying Coda objects versus
regular UNIX files (including UNIX directories) stored within the
Coda filesystem. It will work recursively.
<P>Because the, <B>-f</B> and <B>-o</B>, call the stat(), and open()
functions respectively, resolution many be forced with volmunge
if one is reconstituting a replicated Coda volume or group of volumes
mounted on top of each other.
<P>
SEE ALSO
<H3></H3>
<P>find (1), perl (1)
<P>
<P>
AUTHOR
<H3></H3>
<P>Henry M. Pierce, 1998, created
<P>
\newpage
<H2><A NAME="ss19.15">19.15 histo(3) </A>
</H2>
<P>
NAME
<H3></H3>
<P>histo - histogram package
<P>
<P>
SYNOPSIS
<H3></H3>
<P>#include <histo.h>
<P>
<P>InitHisto (hg, lolimit, hilimit, bucketcount, ht)
<P>struct hgram *hg;
<P>double lolimit;
<P>double hilimit;
<P>int bucketcount;
<P>enum htype ht;
<P>
<P>UpdateHisto (hg, newval)
<P>register struct hgram *hg;
<P>double newval;
<P>
<P>PrintHisto (outfile, hg)
<P>FILE *outfile;
<P>register struct hgram *hg;
<P>
<P>PlotHisto (outfile, hg, graphtitle, xtitle, ytitle, psfileprefix)
<P>FILE *outfile;
<P>struct hgram *hg;
<P>char *graphtitle;
<P>char *xtitle;
<P>char *ytitle;
<P>char *psfileprefix;
<P>
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This is a statistics package that can be used to produce the mean, standard
deviation and histogram of a set of numbers. The histogram can be one of
three types: linear, log2 or log10.
<P>
<P>The package is used by calling the following routines:
<P>
<DL>
<DT><B><EM>InitHisto ()</EM></B><DD><P>initialises the histogram hg by setting the
lolimit, hilimit, bucketcount, and histogram type as specified by the user.
lolimit specifies the origin of the horizontal axis. hilimit specifies the
maximum value on the horizontal axis. It is required that hilimit be greater
than the largest value of the input data. The histogram type htype is
specified as LINEAR = 1, LOG2 = 2, or LOG10 = 3.
<P>
</DL>
<P>
<DL>
<DT><B><EM>UpdateHist ()</EM></B><DD><P>updates the histogram hg with newvalue to
be entered.
<P>
</DL>
<P>
<DL>
<DT><B><EM>PrintHisto ()</EM></B><DD><P>provides the user with statistics for the
input data. Statistics include the mean, standard deviation, and the 90%
confidence interval.
<P>
</DL>
<P>
<DL>
<DT><B><EM>PlotHisto ()</EM></B><DD><P>the output of this file is used as input to
the program csplot to produce a histogram of the input data.
<P>
</DL>
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>Negative return values indicate errors.
<P>
<P>
<P>
EXAMPLE
<H3></H3>
<P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
#include <libc.h>
#include "histo.h"
#define MAX 3
main ()
{
int i, rc, bucketcount;
struct hgram histogram1;
double data[MAX], lolimit1,hilimit1;
enum htype scale = LINEAR;
FILE *fp1;
data[0] = 5;
data[1] = 15.4;
data[2] = 10.6;
bucketcount = 10;
lolimit1 = 0;
hilimit1 = 20;
fp1 = fopen ("result1","w");
if (fp1 == (FILE*) NULL) printf ("Cannot open\\n");
rc = InitHisto (&histogram1, lolimit1, hilimit1, bucketcount, scale);
if (rc < 0) printf ("Initialisation failed\\n");
for (i = 0; i < MAX; i++) UpdateHisto (&histogram1, data[i]);
PrintHisto (fp1, &histogram1);
fclose (fp1);
}
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>M.Satya, 1991
<P>
<P>
\newpage
<H2><A NAME="ss19.16">19.16 timing(3) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>timing_paths - timing package
<P>
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P>#include <timing_paths.h>
<P>#include <histo.h>
<P>#include <dtcreg.h>
<P>
<P>ti_init ()
<P>
<P>ti_create (nEntries, thistie)
<P>int nEntries;
<P>struct tie *thistie;
<P>
<P>ti_notetime (thistie, id)
<P>struct tie *thistie;
<P>long id;
<P>
<P>ti_postprocess (thistie, twrt)
<P>struct tie *thistie;
<P>enum timewrt twrt;
<P>
<P>ti_discoverpaths (thistie, pinfo)
<P>struct tie *thistie;
<P>struct pths_info *pinfo;
<P>
<P>ti_stat (thistie, pinfo)
<P>struct tie *thistie;
<P>struct pths_info *pinfo;
<P>
<P>ti_destroy (thistie)
<P>struct tie *thistie;
<P>
<P>ti_end ()
<P>
<P>
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This package may be used to time sections of a program. Time values are
noted by placing probes in the code at points specified by the user. At each
probe location a time value is obtained from a timer. These recorded time
values are used to compute the times elapsed between consecutive probes.
As an additional feature, for multiple runs of the same program, the package
provides first and second order statistics for the elapsed time between
consecutive probes. This package only works for timing experiments that take
less than 35 minutes to run.
<P>
<P>The package is used by calling the following routines:
<P>
<DL>
<DT><B><EM>ti_init ()</EM></B><DD><P>initialises the timer.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_create ()</EM></B><DD><P>allocates storage for n entries, where n corresponds to the total number of times ti_notetime () is called.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_notetime ()</EM></B><DD><P>probes are placed in different
sections of the code by calling ti_notetime (). Each probe has to be
given a unique id number. In order for the program to function correctly it
is necessary that a probe with id 0 is placed at the very beginning of the
code being timed.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_postprocess ()</EM></B><DD><P>the times obtained from all the
ti_notetime () calls are processed by the ti_postprocess ()
routine. The ti_postprocess () routine can produce the time at each
probe with respect to either the very first probe (twrt = BASELINE) or the
previous probe (twrt = DELTA).
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_discoverpaths ()</EM></B><DD><P>for multiple
iterations of the code being timed, different paths might be followed each
time. A path corresponds to a set of ids beginning with 0, such as
(0 1 2, 0 1 4). ti_discoverpaths identifies all the different paths traversed,
the number of times each path was traversed and other relevant information.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_stat ()</EM></B><DD><P>for each path traversed by the program, ti_stat provides the user with useful statistics (such as mean and standard deviation), for the elapsed time between probes.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_destroy ()</EM></B><DD><P>frees the storage used by the package.
<P>
</DL>
<P>
<DL>
<DT><B><EM>ti_end ()</EM></B><DD><P>releases the timer.
<P>
</DL>
<P>
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>All successful calls return 0. Negative return values indicate errors. In particular -2 is returned by ti_postprocess if the experiment runs more than 35 minutes.
<P>
<P>
<P>
EXAMPLE
<H3></H3>
<P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
#include <timing_paths.h>
#include <histo.h>
#include <dtcreg.h>
main ()
{
int i,j, foo, iterations = 10;
int probes = 3;
struct tie array_info;
struct pths_info paths;
ti_init ();
ti_create (probes*iterations, &array_info);
for (i=0; i<iterations; i++)
{
ti_notetime (&array_info, 0);
ti_notetime (&array_info, 1);
for (j=0; j<10; j++)
{
foo = foo +j;
}
ti_notetime (&array_info, 2);
}
ti_postprocess (&array_info, BASELINE);
ti_discoverpaths (&array_info,&paths);
ti_stat (&array_info,&paths);
ti_destroy ();
ti_end ();
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Gowthami Rajendran, 1991
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.17">19.17 backuplogs(5) </A>
</H2>
<P>
NAME
<H3></H3>
<P>backuplogs.<DDMMMYY> - Format of a Coda backup log file
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>A backuplog is created each day with day, month and year
appended to the name "backuplogs". The file backuplogs contains
the following information collected by the backup and BSD dump
programs:
<UL>
<LI>the cloning process of each replica that makes up a Volume<P>
</LI>
<LI>the dump of each replica to local tape<P>
</LI>
<LI>Attempts to retry failed operations such as unable to contact a server<P>
</LI>
<LI>Successfully volumes (incrementals are marked, otherwise full backups are assumed<P>
</LI>
<LI>Lists any volumes that failed to be backed up<P>
</LI>
<LI>Lists any partially backup volumes (e.g if a replica was missed)<P>
</LI>
<LI>BSD Dump statistics<P>
</LI>
<LI>the disk image file names dumped to tape<P>
</LI>
</UL>
<P>This file may be used to identify successful, partially successful,
partially failed, or complete failures of a backup to occur. It is
also used to identify the replica file names that make up a Volume
to used by <EM>merge</EM>(8) to restore a replica. Also note
that the BSD restore command is used to retrieve files from a tape
listed in the backuplogs.<date> file. Restore should be done
via restore(1) command provided by the BSD-DUMP facility. The the
most recent incremental(s) are then merged with the most recent full backup
of a volume.
<P>
<P>
EXAMPLE
<H3></H3>
<P>
<P>
<HR>
<PRE>
date: Mon 01/05/98
00:05:26 Partition /backup1: 2561728 available size (1K blocks, minfree=5%), 256
1715 free blocks.
00:05:26 Partition /backup2: 2561728 available size (1K blocks, minfree=5%), 256
1715 free blocks.
00:05:26 Partition /backup3: 2559782 available size (1K blocks, minfree=5%), 255
9767 free blocks.
00:05:26 VLDBLookup: VLDB_size unset. Calling VCheckVLDB()
00:05:26 7f0003f4: cloning
00:05:29 e20000af->e20000b0
00:05:33 e10000bd->e10000be
00:05:36 e30000ae->e30000af
00:09:34 7f0003ef: cloning
00:09:57 e2000093->e20000ad
00:10:27 e10000a1->e10000bb
00:10:57 e3000092->e30000b4
00:29:02 Dumping 7f0003f4.e20000af to /backup1/05Jan1998/massenet.coda.cs.cmu.ed
u-7f0003f4.e20000af ...
00:29:02 Transferred 112131 bytes
00:29:02 Dumping 7f0003f4.e10000bd to /backup2/05Jan1998/poulenc.coda.cs.cmu.edu
-7f0003f4.e10000bd ...
00:29:03 Transferred 112131 bytes
00:29:03 Dumping 7f0003f4.e30000ae to /backup1/05Jan1998/rameau.coda.cs.cmu.edu-7f0003f4.e30000ae ...
00:29:14 Transferred 3768325 bytes
01:12:12 Dumping 7f0003ef.e2000093 to /backup1/05Jan1998/massenet.coda.cs.cmu.edu-7f0003ef.e2000093 ...
01:18:31 Transferred 119182513 bytes
01:18:31 Dumping 7f0003ef.e10000a1 to /backup2/05Jan1998/poulenc.coda.cs.cmu.edu-7f0003ef.e10000a1 ...
01:33:44 Transferred 119182513 bytes
01:33:44 Dumping 7f0003ef.e3000092 to /backup3/05Jan1998/rameau.coda.cs.cmu.edu-7f0003ef.e3000092 ...
01:42:03 Transferred 119172268 bytes
03:58:16 Transferred 309842 bytes
03:58:19
03:58:19 Attempting to retry any failed operations.
03:58:19
03:58:19 Successfully backed-up Volumes:
03:58:19 0x7f0003f4 (incremental) f:u.satya2
03:58:19 0x7f0003ef f:u.mre
03:58:19 Only partially successfully backed-up Volumes:
03:58:19
03:58:19 Volumes that FAILED backup:
03:58:19
03:58:19 Volumes that were NOT backed-up:
03:58:19 0x7f000394 t.test
[STATISTICAL SUMMERIES OF THE DUMP NORMALLY APPEAR HERE]
---------> Partition /backup:
---------> command: mt -f /dev/nst0 rewind
---------> command: restore -b 500 -s 1 -f /dev/nst0 -t /
Level 0 dump of /backup on dvorak.coda.cs.cmu.edu:/dev/sda1
Label: none
Dump date: Mon Jan 5 04:05:14 1998
Dumped from: the epoch
2 .
11 ./lost+found
2041 ./05Jan1998
4081 ./05Jan1998/massenet.coda.cs.cmu.edu
4082 ./05Jan1998/massenet.coda.cs.cmu.edu/7f0003f4.e20000af
4087 ./05Jan1998/massenet.coda.cs.cmu.edu/7f0003ef.e2000093
6121 ./05Jan1998/poulenc.coda.cs.cmu.edu
6122 ./05Jan1998/poulenc.coda.cs.cmu.edu/7f0003f4.e10000bd
6127 ./05Jan1998/poulenc.coda.cs.cmu.edu/7f0003ef.e10000a1
8161 ./05Jan1998/rameau.coda.cs.cmu.edu
8162 ./05Jan1998/rameau.coda.cs.cmu.edu/7f0003f4.e30000ae
8167 ./05Jan1998/rameau.coda.cs.cmu.edu/7f0003ef.e3000092
</PRE>
<HR>
SEE ALSO
<H3></H3>
<P>backup (8), dump (1), restore (1), dumplist (5), vicetab (5), merge (8)
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1993, Taken from the System Administrators Guide.
<P>Henry M. Pierce, 1998, updated.
<P>
\newpage
<H2><A NAME="ss19.18">19.18 dumpfile(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>dump file - Format of a dump file
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The dump files are formatted as tagged byte streams. Each piece of the dump is
marked by a tag byte, a number between 1 and 20. Each piece may also be broken
into subpieces, each marked by a letter of the alphabet. Each subpiece is
uniquely marked, but tags can be reused in different parts of the dump.
<P>The first 60 bytes of the
dump contain header information. This header info identifies which backup
volume was used to create the dump, and when and from which volume
the backup clone
was created. It also indicates whether the dump was incremental, and provides
information to be used later in placing this dump in the proper sequence for
merging. Following the dump header is the volume information
structure used by the Coda internals.
Following this are two sequences of vnodes, one for directories and
one for files. Each sequence consists of a header and a stream of vnodes.
<P>The vnode sequence header contains the number of vnodes and the size of the vnode
list. These numbers are not necessarily the same since not every list needs to
have a vnode on it and some lists may have more than one. This is an artifact
of the way vnodes are stored in the Coda servers.
<P>After these two fields comes a list of vnodes. Each vnode consists of two
parts, the first is the meta information associated with the file or
directory and the second is the data for that vnode. This data could either be
directory pages or file data. The first word after the tag for the file or
directory data is a count of bytes or directory pages.
For directory vnodes, the access list for that
directory is included as part of the meta information.
<P>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>backup (8), dumplist (5), volutil (8)
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1993, Taken from system adminstrators guide.
<P>
\newpage
<H2><A NAME="ss19.19">19.19 dumplist(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>dumplist - List of volumes to be archived by the Coda backup mechanism
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The dumplist file contains information for the <B>backup</B>(8) program. It consists of a list of volumes to be archived.
<P>Each entry in the list
contains three tab separated fields: the volumeId (groupId), the schedule for full
and incremental dumps, and a comment used to facilitate reading the output of the
<B>backup</B> program. The schedule contains a number of "F" and "I" characters. Each
character represents what form of dump to take for that day in the schedule. The length
of the period is the number of characters in the schedule. For instance, "FIIIIII"
means take one full dump followed by 6 incrementals, whereas "F" means take a full
dump every day. For convenience, the first character in a 7 day schedule refers to Sunday.
<P>
<P>
<P>
EXAMPLE
<H3></H3>
<P>The following does a full backup of <EM>coda_root</EM>, <EM>coda_root.i386</EM>, and
<EM>coda_root.tmp</EM> on Monday while it does a full backup of
<EM>coda_root.project</EM> and <EM>coda_root.usr</EM> on Wednesday. It uses
<EM>/vicepa/backup</EM> and <EM>/usr/codabackup/backup</EM> to store the dump files.
<BLOCKQUOTE><CODE>
<PRE>
7F000000 IFIIIII coda_root
7F000001 IFIIIII coda_root.i386
7F000002 IIIFIII coda_root.project
7F000003 IFIIIII coda_root.tmp
7F000004 IIIFIII coda_root.usr
7F000005 IFIIIII coda_root.misc
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
NOTES
<H3></H3>
<P>In prior release of coda, the key words "Partition" and "Volumes" were
used to distinguish between seperate sections of the dump file needed
by <CODE>backup</CODE>. <CODE>dumplist</CODE> should now only include the
Volume backup information and does not need the key word Volume. Nor
is the keyword Partitions needed any more as <CODE>backup</CODE> reads
vicetab for backup partition information.
<P>
SEE ALSO
<H3></H3>
<P>backup (8), creatvol (8), createvol_rep (8), vicetab (5)
<P>
<P>
AUTHOR
<H3></H3>
<P>David C. Steere, 1991, Created
updated 1998, hmp
<P>
\newpage
<H2><A NAME="ss19.20">19.20 groups.coda(5) </A>
</H2>
<P> \newpage
<H2><A NAME="ss19.21">19.21 maxgrpid(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>maxgroupid - replicated volume number allocation mechanism
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The system control machine (SCM) has a file, <EM>/vice/vol/maxgroupid</EM>, which contains the maximum replicated (aka group) volume number that has ever been allocated in the system.
This is used as a simple way to guarantee that group volume numbers are unique.
<P>Replicated (or group) volume ids are allocated out of the same
namespace as replica ids and non-replicated volumes ids. The latter
two types of ids have a 1 byte (8 bit) prefix to identify the server
on which they are stored. We suggest using prefixes in the range
00-7F for replicated volume ids, and prefixes in the range 80-FF for
other volumes. When initializing a system, put the number you wish to
use for the first replicated volume in <EM>/vice/vol/maxgroupid</EM>. For
example, if you wish to use 7f000000 as the first replicated volume,
create <EM>/vice/vol/maxgroupid</EM> with the number 2130706432.
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/vol/maxgroupid</EM> on the SCM
<P>
<P>
<P>
BUGS
<H3></H3>
<P>This file should be salvaged, but it is not.
<P>Removing this file (without reinitializing the whole system) is a recipe for disaster.
Grave confusion will result if group (or any other) volumes are created with the same number.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>servers (5), createvol_rep (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.22">19.22 mcstagen(5) </A>
</H2>
<P>
NAME
<H3></H3>
<P>multicastagents - multicastagents file specification
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>
<P>This text file lists all the multicast agents known to the system. It is read
by each magent daemon to learn the IP addresses of its colleagues and the
range of transient IP multicast addresses that it is allowed to allocate.
Each line describes one multicast agent, according to the following format:
<BLOCKQUOTE><CODE>
<PRE>
<agent address> <min allocation address> <max allocation address> <comments>
</PRE>
</CODE></BLOCKQUOTE>
<P>All addresses are in internet dot format (a.b.c.d).
Allocation addresses must be valid class D addresses, i.e., in the range 224.0.0.0 to 239.255.255.255.
<P>
<P>
<P>
FILES
<H3></H3>
<P>/etc/multicastagents
<P>
<P>
<P>
BUGS
<H3></H3>
<P>This file is applicable only for multicast support as specified in RFC-988.
A new multicast support specification, RFC-1054, has been released which supercedes RFC-988.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>magent (8), multicastgroups (5), RFC-988
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.23">19.23 mcstgrps(5) </A>
</H2>
<P>
NAME
<H3></H3>
<P>multicastgroups - multicastgroups file specification
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This text file lists all the permanent IP multicast addresses and their
corresponding membership keys. It is read by each magent daemon. Each line
describes one multicast group, according to the following format:
<BLOCKQUOTE><CODE>
<PRE>
<multicast address> <key-high> <key-low> <group name>
</PRE>
</CODE></BLOCKQUOTE>
<P>All addresses are in internet dot format (a.b.c.d), and must be valid class D
addresses, i.e., in the range 224.0.0.0 to 239.255.255.255. Membership keys
are represented as a pair of 32-bit hex numbers. Unrestricted groups should
have null keys (i.e., 00000000).
<P>
<P>
<P>
FILES
<H3></H3>
<P>/etc/multicastgroups
<P>
<P>
<P>
BUGS
<H3></H3>
<P>This file is applicable only for multicast support as specified in RFC-988.
A new multicast support specification, RFC-1054, has been released which supercedes RFC-988.
<P>Only unrestricted groups should be used.
The protection offered by restricted groups is bogus, and was never tested.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>magent (8), multicastgroups (5), RFC-988
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.24">19.24 servers(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>servers - map server names to numbers
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>Each file server has a file, <EM>/vice/db/servers</EM>, which maps server names to numbers.
The server numbers are 8 bit numbers so a maximum of 256 servers can be supported.
Once a server number has been assigned, it may <B>not</B> be reused.
You should not reassign a server a new id without initializing the server.
<P>The server numbers are used in too many places, probably the most important is
in the creation of volumes. The server creating a volume uses its server number
as the first byte of the four-byte volume identification number in order to ensure uniqueness.
<P>NOTE: Replicated volume numbers must also be unique, so we reserve part of the range,
0-127 (0-7F hex), for this purpose. Real server numbers must <B>not</B> be allocated from
the other subrange, and vice-versa.
<P>The format of the file is the full server name (e.g. mahler.coda.cs.cmu.edu)
followed by a tab and then the servers number. Any line beginning with a "\#"
is considered a comment and is ignored. The following is an example servers
file:
<P>
<BLOCKQUOTE><CODE>
<PRE>
MAHLER.CODA.CS.CMU.EDU 201
GRIEG.CODA.CS.CMU.EDU 204
HAYDN.CODA.CS.CMU.EDU 205
WAGNER.CODA.CS.CMU.EDU 206
DEBUSSY.CODA.CS.CMU.EDU 212
SCARLATTI.CODA.CS.CMU.EDU 214
ROSSINI.CODA.CS.CMU.EDU 215
PUCCINI.CODA.CS.CMU.EDU 216
GERSHWIN.CODA.CS.CMU.EDU 218
SCHUMANN.CODA.CS.CMU.EDU 219
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>
<P>
FILES
<H3></H3>
<P>/vice/db/servers
<P>
<P>
BUGS
<H3></H3>
<P>The server numbers and replicated volume prefixes are pulled from the same number space.
Separation is enforced only by convention.
<P>This file and /vice/db/hosts should be combined.
<P>
<P>
SEE ALSO
<H3></H3>
<P>vrdb (5), vsgdb (5), maxgroupid (5), hosts (5)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Maria R. Ebling, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.25">19.25 user.coda(5) </A>
</H2>
<P> \newpage
<H2><A NAME="ss19.26">19.26 passwd.coda(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>passwd.coda - Coda user identification file
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>This file specifies initial cleartext passwords for Coda users. The
format of the file is:
<P>
<BLOCKQUOTE><CODE>
<PRE>
uid<TAB>acutal cleartext password<TAB>any desired info
</PRE>
</CODE></BLOCKQUOTE>
<P>Where:
<P>
<DL>
<DT><B><B>ViceId</B></B><DD><P>is a Coda user id.
<DT><B><B>Cleartext Password</B></B><DD><P>is the password to use for this <EM>ViceId</EM>.
<DT><B><B>Other user info</B></B><DD><P>is other information about
the user you want to include, e.g. the user name
</DL>
<P>WARNING this file must be owned by root and not be readable by any other user.
<P>This file is translated into a Coda encrypted password file by initpw(8).
<P>
SEE ALSO
<H3></H3>
<P>initpw(8), vice.pcf(5), pwd2pdb(8)
<P>
AUTHOR
<H3></H3>
<P>
<P>Lesa Gresh, 1998, created
\newpage
<H2><A NAME="ss19.27">19.27 vicetab(5) </A>
</H2>
<P>
NAME
<H3></H3>
<P>vicetab - Vice Filesystem Table
<P>
DESCRIPTION
<H3></H3>
<P><EM>vicetab</EM> is a table of Coda data partitions found on individual
servers comprising a Coda netowrk server. This includes partition(s) used
by the backup coordinator to store dump files to placed on a suitable backup
media. This file must be shared among all machines comprising a Coda hub so
edits should be done only on the designated SCM.
For example:
<P><CODE>tye /vicepa ftree depth=5,width=8
tye /vicepb ftree width=8,depth=5 taverner /vicepa ftree width=8,depth=5
taverner /usr/vicepb ftree depth=4,width=8
tallis /vicepa ftree width=8,depth=5
tallis /vicepb ftree width=8,depth=5
dvorak /backup1 backup
dvorak /backup2 backup
dvorak /backup3 backup</CODE>
<P>where column 1 specifies the server as returned by the system call
gethostbyname().
<P>Column 2 specifies the directory of the Coda data tree which must be
a local file system partition for optimal performance.
<B>NOTE:</B><EM>if a server serves than more
than one Coda data parition, each data partition must have a seperate
entry in vicetab.</EM>
<P>Column 3 specifies the Coda partition type.
<UL>
<LI><EM>ftree</EM> an "inode number" directory and file naming system for
storing the Coda filesystem into a local file system tree structure:
e.g. inode 4711 in base 10 with width 1 and depth 5 would become 0/4/7/1/1.
So, using the above example, a width of 4 and a depth of 2 would make
the file name 4/711. If this storage type is specified, the width and
depth must also be given in the 4th column seperated by a comma.</LI>
</UL>
<P>Column 4 specifies the width and depth of the ftree.
<UL>
<LI><EM>width</EM> the maximum "width" of an ftree data partition. </LI>
</UL>
<UL>
<LI><EM>depth</EM> the maximum "depth" of an ftree data partition.</LI>
</UL>
<P>In the case of the backup coordinator, only the first three
columns are used, with a partition type of <CODE>backup</CODE> specified
in the third column.
<P>This file should only be edited on the designated SCM machine and then
allowed to propagate.
FILES
<H3></H3>
<P><EM>/vice/bin/makeftree</EM>
<P>
<P>
BUGS
<H3></H3>
<P>
<P>None we currently are aware of.
<P>
SEE ALSO
<H3></H3>
<P>makeftree (8)
<P>
AUTHOR
<H3></H3>
<P>Henry M. Pierce, 1997, created
<P>
\newpage
<H2><A NAME="ss19.28">19.28 volulist(5) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>volumelist - volumelist file specification
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>Every server keeps a list of volumes for which it is the custodian. This list
is in <EM>/vice/vol/VolumeList</EM>. Every time a volume is created, an entry
corresponding to that volume is made in this list. <EM>bldvldb.sh</EM>(8)
uses this list to generate the Volume Location Data Base (VLDB).
<P>The first few lines of this file contain information pertaining to the
disk partitions. These lines have the following format:
<P>P<partition-name> H<hostname> T<total usable space on this
partition> F<free space on this partition>
<P>There is one line entry for each volume on the server. Each line begins with
W, R or B depending on whether the volume is read-Write, Readonly or Backup.
The format is as follows:
<P>R|W|B<volume-name> I<volume-id> H<server id> P<partition
name> m<min quota>
M<max quota> U<disk space used> W<parent id> C<creation
date> D<copy date>
B<backup date> A<volume usage>
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/vol/VolumeList</EM>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>createvol (8), createvol_rep (8), volutil (8), bldvldb.sh (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Puneet Kumar, 1990, created
<P>
<P>
\newpage
<H2><A NAME="ss19.29">19.29 vrdb(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>vrdb - Volume Replication Data Base specification
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The volume replication data base is stored in binary form in /vice/db/VRDB on each file server.
The <EM>makevrdb</EM> option of the <EM>volutil</EM>(8) program constructs the VRDB on the system control machine (SCM).
<P>The data base consists of fixed-length records, each of which describes a replicated (aka group) volume.
Each file server copies the VRDB into memory at start-up and whenever an updated version of it is received.
The data base is used to map group volume names and numbers into a VSG and the set of read-write volumes which comprise it.
<P>The VRDB is generated from an ASCII version stored on the SCM in /vice/vol/VRList.
The VRList is updated as a side-effect of every create and purge of a replicated volume.
Its format is:
<P><group volname> <group volnum> <# of replicas> <rwvol 1> ... <rwvol 8> <VSG num>
<P>A sample line from the VRList is:
<P><B>project.coda.src 7f000010 3 c9000012 ca000013 cb000013 0 0 0 0 0 E0000107</B>
<P>Note that all volume and VSG numbers are given in hex. Details of the VRDB structure can be found in <vrdb.h>.
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/db/VRDB</EM>
<P><EM>/vice/vol/VRList</EM>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>File servers keep the in-memory copy as a singly-linked list.
It should be converted to a pair of hash-tables, one keyed by group volname, the other by group volnum, for fast lookup.
<P>The maximum number of replication sites is fixed at 8. Adding, deleting, or moving replication sites after creation is not supported.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>volutil (8), maxgroupid (5), vsgdb (5)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, created
<P>
<P>
\newpage
<H2><A NAME="ss19.30">19.30 vrlist(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>vrlist - vrlist file specification
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.31">19.31 vsgdb(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>vsgdb - Volume Storage Group Data Base specification
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The volume storage group data base is stored in ASCII form in <EM>/vice/db/VSGDB</EM> on the system control machine (SCM).
It maps VSG numbers into the sets of servers which comprise them.
Each VSG is represented by a single line with the following format:
<P><VSG number> <server-name 1> ... <server-name n>
<P>VSG numbers are in hexadecimal, and must correspond to a legal multicast address as specified in the multicastgroups (5) file.
Server names must correspond to entries in the servers (5) data base.
There is a limit of 8 on the number of servers in any one VSG.
A sample entry from the VSGDB is:
<P><B>E0000107 mahler vivaldi ravel</B>
<P>The VSGDB is consulted by the <EM>createvol_rep (8)</EM> script when creating a replicated volume.
The VSG number specified is looked up in the VSGDB to determine which sites will host the supporting read-write volumes.
The VSG number is then wired-into the VRList (and then <EM>vrdb) (5)</EM> entry for the new replicated volume.
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/db/VSGDB</EM>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>servers (5), vrdb (5), createvol_rep (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.32">19.32 vstab(5) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>vstab - vstab file specification
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The file <EM>/usr/coda/etc/vstab</EM> contains configuration parameters for
the Coda cache manager, <EM>venus (8)</EM>. The parameters override default
values compiled into Venus, and may themselves be overridden by command-line
arguments supplied to Venus at startup.
<P>The file should contain a single line with the following format:
<P><mount point>:<kernel device>:<default-host list>:<cache
directory>:<cache blocks>:<1>
<P>A sample vstab entry is:
<P><B>/coda:/dev/cfs0:rossini,scarlatti,puccini:/usr/coda/venus.cache:10000:1</B>
<P>Note that the format of the default-host list is
<host<EM>1</EM>,host<EM>2</EM>,...,host<EM>n</EM>>. There should be no
space between the ``:'' separator character and the beginning or end of a
field.
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/usr/coda/etc/vstab</EM>
<P><EM><vstab.h></EM>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>The last parameter is deprecated and should be removed.
<P>This file is also read by <EM>clog (8)</EM> (and perhaps other programs)
which assume that host-list specifies the hosts running auth servers.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>venus (8), vutil (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.33">19.33 au(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>au - add a user
<P>
<P>
<P>
SYNONPSIS
<H3></H3>
<P><B>au</B> [-x] [-h host] [-p portal] <cp | cu | nu | du>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>au</B> is used to add, delete, or change user information. <B>au</B> will first
prompt for a current Coda user name and password. If it can
authenticate using your user name and password, it will proceed to ask
for the new information. <B>au</B> supports the following options:
<DL>
<DT><B><B>-x</B></B><DD><P>Turns on debugging.
<P>
</DL>
<DL>
<DT><B><B>-h</B> <EM>hostname</EM></B><DD><P>Attatch to <EM>hostname</EM> to
do the authentication. <EM>hostname</EM> should be the <EM>SCM</EM>.
<P>
</DL>
<DL>
<DT><B><B>-p</B> <EM>portal</EM></B><DD><P>Port to bind to. The default
portal is coda_auth.
<P>
</DL>
<DL>
<DT><B><B>cp</B></B><DD><P>Change password. Use this to change a
users vice password.
<P>
</DL>
<DL>
<DT><B><B>cu</B></B><DD><P>Change user information. Use this to
change password and other user information.
<P>
</DL>
<DL>
<DT><B><B>nu</B></B><DD><P>New user. The <B>nu</B> option tells <B>au</B>
to add a new password entry to the vice password database.
<P>
</DL>
<DL>
<DT><B><B>du</B></B><DD><P>Delete user. The <B>du</B> option tells
<B>au</B> to delete the given user from the password database.
<P>
</DL>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>You must be a Coda system administrator to ru <B>au</B>.
<P>
<P>
<P>
BUGS
<H3></H3>
<P><B>au</B> echos new passwords to the terminal as they are typed in.
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2
<P>Joshua Raiff, 1993, Created man page
<P>
<P>
\newpage
<H2><A NAME="ss19.34">19.34 auth2(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>auth2 - authentication server
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>auth2</B> [-r] [-chk] [-x debuglevel] [-p pwfile] [-tk tokenkey] [-fk filekey]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>auth2</B> is the Coda authentication server. Clients need to have an
authentication token from <B>auth2</B> in order to establish
authenticated connections to Coda file servers.
<P><B>auth2</B> supports the following commands line options:
<DL>
<DT><B><B>-r</B></B><DD><P>Tells <B>auth2</B> to print log entries to
the controlling tty rather than a log file.
<P>
</DL>
<P>
<DL>
<DT><B><B>-chk</B></B><DD><P>Causes <B>auth2</B> to only validate
passwords. New password entries cannot be added via this server
instance. Servers started with the <B>-chk</B> option are slave servers.
There should only be one master server in the system.
<P>
</DL>
<P>
<DL>
<DT><B><B>-x</B> <EM>debuglevel</EM></B><DD><P>Sets the server debug
level. This level controls the amount of debugging information printed
by the server.
<P>
</DL>
<P>
<DL>
<DT><B><B>-p</B> <EM>pwfile</EM></B><DD><P>Used to tell <B>auth2</B> where
its password file is. Typically this file is /vice/db/auth2.pw.
<P>
</DL>
<P>
<DL>
<DT><B><B>-tk</B> <EM>tokenkey</EM></B><DD><P>Specifies where the token
key file <B>auth2</B> should use when encrypting tokens.
<P>
</DL>
<P>
<DL>
<DT><B><B>-fk</B> <EM>filekey</EM></B><DD><P>Name of file containing the key
decrypt password file with.
<P>
</DL>
<P>
<P>
SEE ALSO
<H3></H3>
<P>authmon (8)
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2.
<P>Joshua Raiff, 1993, Created man page.
<P>
\newpage
<H2><A NAME="ss19.35">19.35 backup(8) </A>
</H2>
<P>
NAME
<H3></H3>
<P>backup - Volume by volume backup of the Coda File System
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>backup</B> [-p poll_period] [-t timeout] <dumplist> [dumpdir]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>backup</B> performs the clone and dump phases of the Coda backup mechanism.
<EM>dumplist</EM> is a file as described in <EM>dumplist</EM>(5). It also
reads <EM>vicetab</EM> which is described in <EM>vicetab</EM>(5) to know
where to place dump files.
<P>The backup program creates many lines of information as the phases progress. It
is a good idea to redirect standard output to a log file. A sample of this log file <EM>backuplogs</EM>(5). After both phases are completed, it prints out a list of volumes in several groupings, and some histograms detailing size and speed of the dumpfiles transferred. The first group are the volumes that were successfully backed up on all servers in their VSG. The second group contains volumes that were successful on some, but not
all of their VSGs. The third group contains volumes that were complete failures.
The last group contains volumes that are in the VLDB or VRDB but not in the
<EM>dumplist</EM>.
<P>The second and third groups use an n-letter word to describe the last successful
operation that succeeded on each replica. The kth position in the n-letter word
corresponds to the kth replica in the VRDB entry for this volume. One of four
letters appears in each position: "L", "C", "D", and "M".
"L" means the replica was only locked, "C" means it was cloned but
not dumped, "D" means it was dumped (but not marked as such on the server,
see the discusion in the manual chapter on backup), and "M" means all phases
completed successfully.
<P><B>backup</B> supports the following command line options:
<DL>
<DT><B><B>-p</B> <EM>poll_period</EM></B><DD><P>Number of seconds to
sleep between polls a servers that <B>backup</B> thinks are down.
<P>
</DL>
<P>
<DL>
<DT><B><B>-t</B> <EM>timeout</EM></B><DD><P>Timout value, in seconds, for RPC2 calls.
<P>
</DL>
<P>
<P>
SEE ALSO
<H3></H3>
<P>volutil (8), dumplist (5), backuplogs (5), Backup chapter of the Coda Manual.
<P>
<P>
AUTHOR
<H3></H3>
<P>David C. Steere, 1991, Created
updated 1998, -hmp
<P>
\newpage
<H2><A NAME="ss19.36">19.36 bldvldb(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>bldvldb.sh - build a new Volume Location Data Base (VLDB)
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>bldvldb.sh</B>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>bldvldb.sh</B> builds a new volume location data base <B>VLDB</B>.
It uses the
<EM>/vice/db/hosts</EM> file to get a list of servers to use to retrieve
the current list of volumes. It gets the list from the
<EM>/vice/vol/VolumeList</EM> file on each server. It combines the list
into <EM>/vice/vol/BigVolumeList</EM> and
passes the combined list as a parameter to the <B>volutil makevldb</B>
command. This command produces a new <B>VLDB</B> in <EM>/vice/db</EM> and
updates the files <EM>AllVolumes</EM> and <EM>partitions</EM> in <EM>/vice/vol</EM>.
You must have root priveledges to run this command.
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>This command can only be issued on the System Control Machine (SCM). Bldvldb uses
two mechanisms to get the VolumeList files from the various servers in
<EM>/vice/db/hosts</EM>. The first is ftp. In order for this to succeed, there has to
be a file called ".anonr" in the directory <EM>/vice/vol</EM>, which is globally
readable and contains a line with the word "VolumeList" in it. If
<B>bldvldb.sh</B> is unable to get the file via ftp, it will attempt to use
the CMU RFS remote file system. If neither mechanism works, <B>bldvldb.sh</B> will
skip over that servers volumes when building the <B>VLDB</B>. The
databases are propagated via the update protocol. This takes up to
five minutes. Attempts to access a new volume from a client, prior to the
propagation of all the databases to all servers, may fail.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<DL>
<DT><B><EM>/vice/vol/AllVolumes</EM></B><DD><P>is created
<P>
</DL>
<DL>
<DT><B><EM>/vice/db/VLDB</EM></B><DD><P>is created
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/VolumeList</EM></B><DD><P>on each server is used to build the VLDB
<P>
</DL>
<DL>
<DT><B><EM>/vice/db/hosts</EM></B><DD><P>is a list of the active servers
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/BigVolumeList</EM></B><DD><P>is the result of combining <EM>/vice/vol/VolumeList</EM> from each server
<P>
</DL>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>update (8), volutil (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Puneet Kumar, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.37">19.37 crvol(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>createvol - create a non-replicated volume
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>createvol</B> <volume-name> <server-name> <partition-name>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>createvol</B> is used to create a Coda non-replicated volume on the specified
partition (<EM><partion-name>)</EM> and server (<EM><server-name>)</EM>. The
volume number is assigned by the server automatically; the name is
specified by the invoker (<EM><volume-name>)</EM>.
<P><B>createvol</B> first checks in <EM>/vice/vol/AllVolumes</EM> to see if the
volume-name already exists. If not, it uses the <EM>volutil create</EM>
command to create the volume at the specified server. It then
uses <EM>bldvldb.sh (8)</EM> to build the Volume Location Data Base (VLDB).
<P>The default access control list of the volume gives the group System:Anyuser
read and lookup rights. The owner of the root directory, as well as a more
reasonable access list, must be set later by a system administrator
using the <EM>cfs</EM>(1) command.
<P>
<P>
EXAMPLE
<H3></H3>
<P>To Create a volume for user "hbovik" on server "mahler":
<BLOCKQUOTE><CODE>
<PRE>
createvol user.hbovik mahler /vicepa
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<P>
NOTES
<H3></H3>
<P>This command does not create the mount point to the volume within the
file system hierarchy. This must be created by the <B>cfs mkmount</B>(1)
command.
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>This command must be issued at the System Control Machine (SCM). Also,
it must be invoked with effective user id of root. This command does not
check for return codes from the servers once the volutil command is
made. The invoker must check by hand in the <EM>/vice/vol/VolumeList</EM> file
on the server to see if the volume name exists at that server.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<DL>
<DT><B><EM>/vice/vol/AllVolumes</EM></B><DD><P>used to find out if volume already exists
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/VolumeList</EM></B><DD><P>name of volume created is appended to it
<P>
</DL>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>cfs (1), bldvldb.sh (8), volutil (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Puneet Kumar, 1990, created
<P>
<P>
\newpage
<H2><A NAME="ss19.38">19.38 crvolrep(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>createvol_rep - create read-write replicated volume
<P>
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>createvol_rep</B> <volume-name> <vsgaddr> <partition-name> [rep group id]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>createvol_rep</B> is a front end to <EM>volutil createvol_rep</EM> and is used to create a Coda read/write replicated volume.
The invoker must specify the volume name (<EM><volume-name>)</EM>,
the replication sites via a Volume Server Group address (<EM><vsgaddr>)</EM>,
the partition on which the volume should be created (<EM><partition-name>)</EM>,
and an optional <EM>Group Id</EM>.
<P><B>createvol_rep</B> first checks in <EM>/vice/vol/AllVolumes</EM> and
<EM>/vice/vol/VRList</EM> to see if the volume name already exists. If not,
it uses the <EM>volutil create_rep</EM> command to create the volume at each of
the replication sites. It then builds the Volume Location Data Base (VLDB)
and the Volume Replication Data Base (VRDB).
<P>The replication sites are determined from the
<EM><vsgaddr></EM> and the <EM>/vice/db/VSGDB</EM> file.
The <EM>Rep Group Id</EM> specifies the "replicated" volumeid of the volume
being created. By default, the group id in <EM>/vice/vol/maxgroupid</EM> is
used. Each time it is used it is also updated by adding 1 to it.
<P>After the replicas are created at each replication site, a new VLDB is built
automatically using <EM>bldvldb.sh</EM>(8), and the Volume Replication
List in <EM>/vice/vol/VRList</EM> is updated. The VRList contains one line for
each replicated volume. Each line specifies the replicated volume name,
group id, number of replication sites,
local volume id at each replication site and
the VSG address. This file is now used to create a new Volume Replication
Data Base (VRDB) using the <EM>"volutil makevrdb /vice/vol/VRList"</EM> command.
<P>
<P>
EXAMPLES
<H3></H3>
<P>To create a replicated volume "coda.rep" on 3 sites foo, bar and gorp use:
<P>
<DL>
<DT><B><B>createvol_rep coda.rep E0000107 /vicapa</B></B><DD><P>
</DL>
<P>where <EM>/vice/db/VSGDB</EM> has an entry "E0000107 foo bar gorp" in it.
<P>To assign a predetermined Group Id, use
<P>
<DL>
<DT><B><B>createvol_rep coda.rep E0000107 /vicepa 7F000003</B></B><DD><P>
</DL>
<P>where "7F000003" is the Group Id.
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>This command must be issued at the System Control Machine (SCM). Also, it
must be invoked with effective user id of root. This command does not check
for return codes from the <EM>volutil create_rep</EM> command. The invoker
must check <EM>/vice/vol/VRList</EM> and <EM>/vice/vol/VolumeList</EM> at each
replication site to see if the volume was created.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<DL>
<DT><B><EM>/vice/vol/VRList</EM></B><DD><P>contains information on replicated volumes
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/VolumeList</EM></B><DD><P>name of volume created at each site is appended to it
<P>
</DL>
<DL>
<DT><B><EM>/vice/db/VRDB</EM></B><DD><P>is used to describe the replicated volumes in terms of its non-replicated members.
<P>
</DL>
<DL>
<DT><B><EM>/vice/db/VSGDB</EM></B><DD><P>is used to translate the VSG address to replication sites
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/AllVolumes</EM></B><DD><P>is used to check if volume exists
<P>
</DL>
<DL>
<DT><B><EM>/vice/vol/maxgroupid</EM></B><DD><P>is used to assign a group id to the replicated volume
<P>
</DL>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>bldvldb.sh (8), volutil (8), createvol (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Puneet Kumar, 1990, Created
<P>
<P>
<P>
<P>
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.39">19.39 initpw(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>initpw - Initialize the auth2 password database.
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>initpw</B> [-k key]
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>initpw</B> initializes the <EM>auth2</EM> password database by
reading entries as specified in passwd_coda(5) and writes the
corresponding encrypted entries to stdout.
<B>initpw</B> supports the following command line options:
<DL>
<DT><B><B>-k</B> <EM>key</EM></B><DD><P>Using the <B>-k</B> option allows
you to specify the encryption key to use when encrypting cleartext
passwords. Currently you must give "drseuss " as the key.
<P>
</DL>
<P><B>initpw</B> expects to receive lines of the form:
<BLOCKQUOTE><CODE>
<PRE>
<ViceId> <Clear Password> <Other user info>
</PRE>
</CODE></BLOCKQUOTE>
See passwd.coda(5).
<P>
EXAMPLE
<H3></H3>
<P>initpw -k "drseuss " < /vice/db/passwd.coda > /vice/db/auth2.pw
<P>
<P>
SEE ALSO
<H3></H3>
<P>auth2 (8), passwd.coda(5)
<P>
<P>
AUTHOR
<H3></H3>
<P>1987, Adapted from AFS-2
<P>Joshua Raiff, 1993, Created man page
<P>Lesa Gresh, 1998, modified
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.40">19.40 makeftree(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>makeftree - format a Coda Data Storage partition to use b-tree structure.
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>makeftree</B> <vicetab;gt; <partition_path>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><CODE>makeftree</CODE> organizes an existing UNIX directory with a mounted partition
for use by Coda listed in vicetab with an ftree format for fast and efficent
file retrival. The ftree infromation is kepe in the file <EM>FTREEDB</EM> at
the head of the partition.
<P>The depth and width must be specifed in <CODE>vicetab</CODE>
<P>
BUGS
<H3></H3>
<P><CODE>makeftree</CODE> expects the file FTREEDB to already exist before it is run.
Before running
<BLOCKQUOTE><CODE>
<PRE>
touch /<partition_path>/FTREEDB.
</PRE>
</CODE></BLOCKQUOTE>
must be issued to avoid an abort.
<P>
<P>
SEE ALSO
<H3></H3>
<P>vicetab (5)
<P>
<P>
AUTHOR
<H3></H3>
<P>Henry M. Pierce, 1998, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.41">19.41 merge(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>merge - merge incremental dumps onto full dumps for restore
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>merge</B> <output file> <full dump> <incremental dump>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>merge</B> is a utility that allows one to apply incremental dumps to a full
dump and produce a new full dump which reflects a later state of the volume.
The new dump can then be used to restore the volume, or can be merged with other
incrementals.
<P>An incremental or full dump reflects the state of the volume at the time it
was dumped. Full dumps can be restored so that a user may access an older
state of a volume. Incremental dumps do not necessarily have sufficient
information to be restored. For instance, all the vnodes in the dump may not
be present. The merging process allows a full image of a state that was only
incrementally dumped to be restored.
<P>Currently incrementals apply to the last successful full dump that was done.
As an example, say full dumps for a volume are done on Sundays, with
incrementals being taken the rest of the week. If an administrator wishes to
restore a volume to Wednesdays state, he would have to fetch the full
dumpfile from Sunday and the incremental dumpfile for Wednesday. Once these
are present, the administrator would use the merge program to create a new
updated full dump for Wednesdays state, and restore it to the server (using
volutil(8) restore).
<P>Information in the dump header is used to place a total ordering on the
dumps. This way incrementals can only be applied to the dump with repect to
which they were taken. In addition, incrementals cannot be applied to other
incrementals, and the dumps to be merged must have been created from the same
volume replica. The merge program checks these things, and reports failures
if they are violated.
<P>
<P>
SEE ALSO
<H3></H3>
<P>volutil (8), restore (1)
<P>
<P>
AUTHOR
<H3></H3>
<P>David C. Steere, 1991, created
<P>
<P>
\newpage
<H2><A NAME="ss19.42">19.42 norton(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>norton - Coda file server RVM debugger
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>Norton</B>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><EM>Norton</EM> is a utility program that allows you to display Coda file
server structures that are stored in <EM>RVM</EM>. Eventually, <EM>Norton</EM>
will be a full special purpose debugger that allows you to manipulate
the structures as well. <EM>Norton</EM>s command interface uses the gnu
<EM>readline</EM> library which features Emacs style command editting as
well as maintaining a command history. Command completion is also
supported by using <EM><tab></EM> and <EM><esc>-?]</EM>.
<P>The available commands are:
<DL>
<DT><B><B>show directory</B> <EM><volid> <vnum> <unique></EM></B><DD><P>Lists
the contents of the directory indicated by <EM>volid.vnum.unique</EM>.
Each entries vnode number and uniquifier are also listed.
<P>
</DL>
<P>
<DL>
<DT><B><B>delete name</B> <EM><volid> <vnode> <unique> <file> <flag> </EM></B><DD><P>remove <EM>file</EM> from the directory specified by
<EM>volid.vnode.unique</EM>. If flag is nonzero the linkcount of the directory is reduced by one. <B>NOTE: delete
name does not do anything to the vnodes associated with
<EM>file</EM>, you must remove the vnodes by hand or update
their link count.</B>
<P>
<DT><B><B>delete volume</B> <EM><volid></EM></B><DD><P>mark a volume
with a "destroyme" flag, so that the salvager will destroy it on the
next serverstartup.
</DL>
<P>
<DL>
<DT><B><B>examine</B> <EM><addr> <len></EM></B><DD><P>Print <<EM>len</EM>>
bytes starting from <<EM>addr</EM>> in hex and ascii.
<P>
</DL>
<P>
<DL>
<DT><B><B>list volumes</B></B><DD><P>Display a list of all the
volumes on the server. This list includes the volume index, name,
number, and type.
<P>
</DL>
<P>
<DL>
<DT><B><B>show free</B> <EM>large | small</EM></B><DD><P>Display all of
the vnodes on either the large or small free vnode list.
<P>
</DL>
<P>
<DL>
<DT><B><B>show heap</B></B><DD><P>Display RVM heap usage.
<P>
</DL>
<P>
<DL>
<DT><B><B>show index</B> <EM> <volname> | <volid></EM></B><DD><P>Display
the RVM index of the given volume name or number.
<P>
</DL>
<P>
<DL>
<DT><B><B>show vnode</B> <EM><volid> [ <vnode> | ? </EM> <unique>]</B><DD><P>Show the specified vnode. If a <EM>?</EM> is given rather than a
vnode number, all of the volumes vnode lists are searched for a vnode
with a matching uniquifier.
<P>
</DL>
<P>
<DL>
<DT><B><B>show volume</B> <EM><volname> | <volid></EM></B><DD><P>Show a
summary of the specified volume.
<P>
</DL>
<P>
<DL>
<DT><B><B>show volume details</B> <EM><volname> | <volid></EM></B><DD><P>Show all of the RVM state of the specified volume.
<P>
</DL>
<P>
<DL>
<DT><B><B>create name</B> <EM>< parentvolid>< parentvnode>< parentuniqifier>< name>< childvnode>< childuniqifier></EM></B><DD><P>Insert a vnode in a directory. The parent fid gives
the directory in which name is to be inserted. The child fid refers
to the child vnode. The link count of the directory is increased if
the child is a directory vnode.
<P>
</DL>
<P>
<DL>
<DT><B><B>x</B> <EM><addr> <len></EM></B><DD><P>Print <<EM>len</EM>>
bytes starting from <<EM>addr</EM>> in hex and ascii. An alias for
<B>examine</B>.
<P>
</DL>
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1995, Created.
Peter Braam, 1997, new features.
<P>
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.43">19.43 pcfgen(8) </A>
</H2>
<P> \newpage
<H2><A NAME="ss19.44">19.44 prgvol(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>purgevol - delete a non-replicated volume
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>purgevol</B> <volumename>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>purgevol</B> is a front-end to the <EM>volutil purgevol</EM> command and
is used to delete a non-replicated volume from the Coda system.
<B>purgevol</B> determines the location of the volume using the readable
version of the <EM>VLDB</EM> located in <EM>/vice/vol/AllVolumes</EM>. It
then uses the <EM>volutil</EM> utility to purge the volume at the volumes
site. Finally, it builds a new <EM>VLDB</EM> using the <EM>bldvldb</EM>(8)
script.
<P>Purgevol is similar to the <EM>volutil purge</EM>, except that it accepts
different parameters, can only be run on the SCM, and builds a new vldb. The
user must be root to execute this script.
<P>
<P>
FILES
<H3></H3>
<P>
<P>
<DL>
<DT><B><EM>/vice/vol/AllVolumes</EM></B><DD><P>updated by deleting the entry for
the purged volume.
<P>
</DL>
<P>
<DL>
<DT><B><EM>/vice/vol/VolumeList</EM></B><DD><P>updated by the remote server as a
side effect of purging the volume.
<P>
</DL>
<P>
<P>
SEE ALSO
<H3></H3>
<P>
<P>bldvldb.sh(8), purgevol_rep(8), volutil(8)
<P>
<P>
AUTHOR
<H3></H3>
<P>
<P>David Steere, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.45">19.45 prgvolre(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>purgevol_rep - delete a replicated volume
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>purgevol_rep</B> <volumename>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>purgevol_rep</B> is a front-end to the <EM>volutil
purgevol_rep</EM> command and is used to delete a replicated volume
from the Coda system. <B>purgevol_rep</B> determines the replicated
volumeIds corresponding to this volume by examining the readable version of
the <EM>VRDB</EM> located in <EM>/vice/vol/VRList</EM>. It then uses the
<EM>volutil</EM> utility to purge the individual replicas at the sites of
replication. Next, it removes the entry for the deleted volume from the
<EM>/vice/vol/VRList</EM> and builds a new <EM>VRDB</EM>. Finally, it builds
a new <EM>VLDB</EM> using the <EM>bldvldb</EM>(8) script. Like the other
volume utilities, <B>purgevol_rep</B> must be run on the SCM by
root.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<P>
<DL>
<DT><B><EM>/vice/vol/AllVolumes</EM></B><DD><P>updated by removing the entries for
the replicas of the purged volume.
<P>
</DL>
<P>
<DL>
<DT><B><EM>/vice/vol/VolumeList</EM></B><DD><P>updated by the remote server as a
side effect of purging the volume.
<P>
</DL>
<P>
<DL>
<DT><B><EM>/vice/vol/VRList</EM></B><DD><P>updated by deleting the entry for the
purged volume.
<P>
</DL>
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>bldvldb.sh(8), purgevol(8), volutil(8)
<P>
<P>
AUTHOR
<H3></H3>
<P>David Steere, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.46">19.46 pwd2pdb(8) </A>
</H2>
<P> \newpage
<H2><A NAME="ss19.47">19.47 readdump(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>readdump - Utility to examine dumpfiles created by the Coda backup facility
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>readdump</B> [dumpfile]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The <B>readdump</B> program is an interactive facility to allow the user to
get information from a dump file produced by the Coda backup mechanism. For
now it is simply a way of looking at the information in a dump file. One
cannot use it to modify the dump file.
<P>The <B>readdump</B> program supports the following commands:
<DL>
<DT><B><B>openDumpFile</B> <dumpfile></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>showHeader</B></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>showVolumeDiskData</B></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>setIndex</B> <index type></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>nextVnode</B></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>skipVnodes</B> <nVnodes></B><DD><P>
</DL>
<P>
<DL>
<DT><B><B>quit</B></B><DD><P>
</DL>
<P><B>readdump</B> uses the <EM>ci</EM> command interface, which allows the
use of unique prefixes for commands. Unspecified parameters will be prompted
for, and default values can be used. The <EM>showHeader</EM> command prints
out the header of the dump, which is seperate from the header of the volume
that was dumped. The <EM>showVolumeDiskData</EM> prints out the header of the
volume.
<P>The dump contains two streams of vnodes, one for directories and one for
files and symbolic links. The <EM>setIndex</EM> command specifies to
<B>readdump</B> which stream you wish to examine. Once an index has been
specified, the <EM>nextVnode</EM> command displays the next Vnode (object) in
the stream. Note that movement through the stream is one-directional. To
revisit a Vnode, use the <EM>setIndex</EM> command to reset the program back
to the beginning of the stream. One can jump through the index by use of the
<EM>skipVnodes</EM> command, which takes the number of vnodes to skip, and
reads past (without displaying) that many vnodes in the stream.
<P>
<P>
<P>
Future Work
<H3></H3>
<P>Usage of this facility should suggest more commands to help administrators
parse dumpfiles. In particular, a command to seek ahead to a specified offset
in the dump would be useful.
<P>
<P>
SEE ALSO
<H3></H3>
<P>merge (8), backup (8), volutil (8), Coda Manual
<P>
<P>
AUTHOR
<H3></H3>
<P>David C. Steere, 1991, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.48">19.48 codasrv(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>codasrv - CFS file server
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>codasrv</B> [-d (debug level)] [-rpcdebug rpc2debuglevel] [-p (number of processes)] [-b (buffers)]
<P>[-l (large vnodes)] [-s (small vnodes)] [-k (stack size)]
<P>[-w (wait interval)] [-r (RPC retry count)]
<P>[-o (RPC timeout)] [-c (check interval)]
<P>[-t (RPC trace buffers)] [-forcesalvage]
<P>[-quicksalvage] [-rvm logdevice datadevice length] [-nores]
<P>[-trunc percent] [-nocmp] [-nopy] [-nodumpvm] [-nosalvageonshutdown]
<P>[-mondhost hostname] [-mondportal port] [-debarrenize] [-optstore]
<P>[-rvmopt] [-newchecklevel checklevel]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>codasrv</B> is the CFS <EM>vice</EM> file server. It services requests from
client machines <B>venus</B> processes and maintains the file system.
<P><B>Srv</B>s command line options are:
<DL>
<DT><B><B>-d</B> <EM><debug level></EM></B><DD><P>Sets the internal
debugging level to <EM><debug level></EM>. This controls the amount of
debugging output <B>codasrv</B> will generate.
<P>
</DL>
<P>
<DL>
<DT><B><B>-p</B> <EM><number of processes></EM></B><DD><P>Sets the number
of light weight processes that will be used to handle concurrent
requests.
<P>
</DL>
<P>
<DL>
<DT><B><B>-b</B> <EM>buffers</EM></B><DD><P>Sets the number of internal
buffers used by <B>codasrv</B> for the dir package.
<P>
</DL>
<P>
<DL>
<DT><B><B>-l</B> <EM><large vnodes></EM></B><DD><P>number of large vnodes in lru cache
<P>
</DL>
<DL>
<DT><B><B>-s</B> <EM><small vnodes></EM></B><DD><P>number of small vnodes in lru cache
<P>
</DL>
<DL>
<DT><B><B>-k</B> <EM><stack size></EM></B><DD><P>stack size of LWP threads in Kbytes
<P>
</DL>
<DL>
<DT><B><B>-w</B> <EM><wait interval></EM></B><DD><P>interval for CallBackCheckLWP to see which clients are alive
<P>
</DL>
<DL>
<DT><B><B>-r</B> <EM><RPC retry count></EM></B><DD><P>number of times a call is retried before reporting death
<P>
</DL>
<DL>
<DT><B><B>-o</B> <EM><RPC timeout></EM></B><DD><P>default timeout for all rpcs
<P>
</DL>
<P>
<DL>
<DT><B><B>-c</B> <EM><check interval></EM></B><DD><P>The interval at which shutdown is checked
<P>
</DL>
<DL>
<DT><B><B>-t</B> <EM><RPC trace buffers></EM></B><DD><P>number of entries in the rpc trace buffer
<P>
</DL>
<P>
<DL>
<DT><B><B>-forcesalvage</B></B><DD><P>force a full salvage on all volumes
<P>
</DL>
<DL>
<DT><B><B>-quicksalvage</B></B><DD><P>salvage only the headers of the volumes - currently it always does a full
<P>
</DL>
<DL>
<DT><B><B>-rvm</B> <EM>logdevice datadevice length</EM></B><DD><P>The <B>-rvm</B>
switch allows you to specify the locaction of the log device, data
device, and length of the recoverable segment used by the server. This parameter is not optional.
<P>
</DL>
<DL>
<DT><B><B>-nores</B></B><DD><P>Turn off resolution on the servers
<P>
</DL>
<DL>
<DT><B><B>-trunc</B> <EM>percent</EM></B><DD><P>Specify how full the log can get before
it is truncated. Default is 50%
<P>
</DL>
<DL>
<DT><B><B>-nocmp</B></B><DD><P>Directory replica contents will not be checked for equality at end of resolution
<P>
</DL>
<DL>
<DT><B><B>-nopy</B></B><DD><P>Suppress polling and yielding by threads that run for a long period
<P>
</DL>
<DL>
<DT><B><B>-nodumpvm</B></B><DD><P>Do not dump in-memory copy of recoverable segment before shutdown
<P>
</DL>
<DL>
<DT><B><B>-nosalvageonshutdown</B></B><DD><P>Do not salvage volumes on shutdown
<P>
</DL>
<DL>
<DT><B><B>-mondhost</B> <EM>hostname</EM></B><DD><P>Host where <EM>mond</EM> database is stored
<P>
</DL>
<DL>
<DT><B><B>-mondportal</B> <EM>port</EM></B><DD><P>Port to use when contacting the <EM>mond</EM> host.
<P>
</DL>
<DL>
<DT><B><B>-debarrenize</B></B><DD><P>Create an inode for a vnode if the inode cannot be found by the salvager
<P>
</DL>
<DL>
<DT><B><B>-opstore</B></B><DD><P>Optimized Stores - return to the client before sftp completes
<P>
</DL>
<DL>
<DT><B><B>-rvmopt</B></B><DD><P>Turn on inter/intra transaction rvm optimizations
<P>
</DL>
<DL>
<DT><B><B>-newchecklevel</B> <EM>checklevel</EM></B><DD><P>Set the level of checking done by new plumber.
<P>
</DL>
<P>
<P>
FILES
<H3></H3>
<P>/vice/srv/SrvErr
<P>/vice/srv/SrvLog*
<P>
<P>
SEE ALSO
<H3></H3>
<P>startserver (8)
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1993, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.49">19.49 startserver(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>startserver - Start the CFS file server
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>startserver</B>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>startserver</B> is used to start the CFS file server process. It will
clean up old log files, then start the server. This script is useful
for starting the server with the same configuration every time its run.
<P>
<P>
FILES
<H3></H3>
<P><EM>codasrv</EM>
<P><EM>/vice/srv/SrvErr</EM>
<P><EM>/vice/srv/SrvLog*</EM>
<P><EM>/vice/srv/srv.conf</EM>
<P>
SEE ALSO
<H3></H3>
<P>codasrv (8)
<P>
<P>
AUTHOR
<H3></H3>
<P>Joshua Raiff, 1993, Created man page
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.50">19.50 updtclnt(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>updateclnt - update client executables
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>updateclnt</B> [ -d debug_level ] [ -h host_name ] [ -q service_name ] [ -w wait_interval ] [ -r reps ]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The <B>updateclnt</B> command is a client process to the <EM>updatesrv</EM> process. It is used to keep the binaries and data bases on a file server in sync with those on a control machine. The arguments include:
<P>
<DL>
<DT><B><B>-d</B> <EM>debug_level</EM></B><DD><P>This option changes the debugging level. The higher the debug_level, the more information is printed. Maximum debugging level is 10.
<P>
</DL>
<P>
<DL>
<DT><B><B>-h</B> <EM>host_name</EM></B><DD><P>This is the hostname of the
control machine with which this process keeps up-to-date. Default: scm.
<P>
</DL>
<P>
<DL>
<DT><B><B>-q</B> <EM>service_name</EM></B><DD><P>This is the name in
<EM>/etc/services</EM> that should be used as the connect portal on
the machine specified by <B>host_name</B> above. Default: rupdsrv.
<P>
</DL>
<P>
<DL>
<DT><B><B>-w</B> <EM>wait_interval</EM></B><DD><P>The interval
between probes, in seconds. The lower this number, the quicker the
servers will be updated when a change occurs and the more cpu and network
resources required. Default: 300s (5min).
<P>
</DL>
<P>
<DL>
<DT><B><B>-b</B></B><DD><P>This option forces a .BAK file to be kept for any file that is changed.
<P>
</DL>
<P>
<DL>
<DT><B><B>-r</B> <EM>reps</EM></B><DD><P>This is the number of wait intervals
between long checks. Files are checked at two intervals. The interval
specified by <B>-w</B> is used for those files in <EM>/vice/db</EM>. All
other files are checked once each <B>-r</B> repetitions of length
<B>-w</B>. Default: 6, so the long interval is 30min.
<P>
</DL>
<P><B>Updateclnt</B> checks <EM>/vice/db</EM> every
<EM>wait_interval</EM> seconds. This directory contains a file
called <EM>files</EM>. Each file specified in it has its current date
checked at the server, and a new copy of the file is fetched if the date does
not match that on the control machine. The format of the <EM>files</EM> file
is defined below.
<P>
<P>
EXAMPLES
<H3></H3>
<P>The command <B>updateclnt -h mahler</B> would cause the client machine to
check the host "mahler" every 5 minutes to see if any of the
<EM>/vice/db</EM> files have changed and every 30 minutes to see if any other
files have changed. Normally the command is invoked by issuing the
<B>updatemon (8)</B> command with the same operands.
<P>
<P>
FORMAT
<H3></H3>
<P>The format of the <EM>files</EM> file is one file name per line. A "-" as the first character on the line causes the file to be deleted instead of copied.
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>The updateclnt program can have its debug level turned on while it is running by sending a <B>kill -TSTP</B> signal to a running updateclnt. To reset the debug level back to zero, send a <B>kill -HUP</B> signal to the running updateclnt. This also causes the UpdateLog file to not be written anymore.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<DL>
<DT><B><EM>/vice/srv/UpdateLog</EM></B><DD><P>is the name of the log file for the updateclnt command. It can be viewed by using the command
<EM>tail -f /vice/file/UpdateLog</EM>. It is only written if debugging has been started.
<P>
</DL>
<P>
<DL>
<DT><B><EM>/vice/srv/UpdatePid</EM></B><DD><P>is the pid of the updateclnt process.
<P>
</DL>
<P>
<DL>
<DT><B><EM>/vice/srv/UpdateMon</EM></B><DD><P>is the pid of the updatemon process that is keeping updateclnt running.
<P>
</DL>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>There is no easy way to add to the list of directories checked.
<P>The <EM>-r</EM> option is now obsolete as <B>updateclnt</B> does not update
any directory other then <EM>/vice/db</EM>.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>updatesrv (8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Maria R. Ebling, 1990, Adapted from AFS
<P>
<P>
\newpage
<H2><A NAME="ss19.51">19.51 updtsrv(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>updatesrv - update server files
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>updatesrv</B> [ <B>-d</B> debug_level ] [ <B>-l</B> number_of_lwps ] [ <B>-p</B> prefix ] [ <B>-s</B> ] [ <B>-q</B> service_number ]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P>The <B>updatesrv</B> command is a read-only server that responds to requests for files by name. The operands that it accepts are:
<P>
<DL>
<DT><B><B>-d</B> debug_level</B><DD><P>This is used to increase the level
of messages written to the log file.
<P>
</DL>
<P>
<DL>
<DT><B><B>-l</B> <EM>number_of_lwps</EM></B><DD><P>This operand is
used to specify how many lwps will be used to answer file requests.
Default: 2.
<P>
</DL>
<P>
<DL>
<DT><B><B>-p</B> <EM>prefix</EM></B><DD><P>This name, prefixed to all file
requests, is used to limit the files that can be requested.
<P>
</DL>
<P>
<DL>
<DT><B><B>-q</B> <EM>service_name</EM></B><DD><P>This is the service name
in <EM>/etc/services</EM> that is to be used. Default: rupdsrv.
<P>
</DL>
<P>
<P>
EXAMPLES
<H3></H3>
<P>The command <B>updatesrv -s -p /</B> would invoke the updatesrv process
and cause the files to be served relative to / on the server machine.
<P>The command <B>updatesrv -s -p /vice/bin</B> would cause the files to be
served relative to /vice/bin on the server machine.
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>
<P>The UpdateLog file will contain useful information. Issuing a <B>kill
-TSTP</B> signal to a running updatesrv will increase the level of debugging
messages. The debugging messages can be turned off by issuing a <B>kill
-HUP</B> signal. This will also cause the log file to no longer be written.
<P>
<P>
<P>
FILES
<H3></H3>
<P>
<DL>
<DT><B><B>UpdateLog</B></B><DD><P>This log of the messages from <B>updatesrv</B> is kept in the directory specified by the <B>-p</B> operand on the invocation. This log file is only written when debugging is enabled.
<P>
</DL>
<P>
<DL>
<DT><B><B>pid</B></B><DD><P>This file contains the pid of the updatesrv process. It is kept in the directory specified on the <B>-p</B> operand on invocation of the command.
<P>
</DL>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>It does not yet use any password authentication to stop others from using it to fetch files from servers.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>checkvenus(8)
updateclnt(8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Maria R. Ebling, 1990, Adapted from AFS-2
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.52">19.52 venus(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>venus - client cache manager
<P>
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>venus</B> [ -k kernel device ] [ -h host list ] [ -cf cache files ] [ -c cache blocks ] [-mles CML entries]
<P>[ -d debug level ] [-rpcdebug rpc2debuglevel] [ -r root volume ] [ -f cache directory ] [ -m COP modes ]
<P>[ -mc 0 | 1 ] [ -console console file ] [ -retries RPC2 retries ] [ -timeout RPC2 timeout ]
<P>[ -ws SFTP window size ] [ -sa SFTP send ahead ] [ -ap SFTP ack point ] [ -init ] [ -p ]
<P>[ -hdbes hoard entries] [-rvmt RVM type] [-sim infile outfile filtfile systype]
<P>[ -mondhost hostname] [ -mondport port ] [ -maxprefetchers fetch threads ]
<P>[ -maxworkers work threads] [ -maxcbservers cb threads ] [ -vld device ] [ -vlds size ]
<P>[-vdd device ] [ -vdds size ] [ -rdscs chunk size ] [ -rdsnl nlists ] [ -logopts 0 | 1 ]
<P>[ -swt weight ] [ -mwt weight ] [ -ssf scale factor ] [ mount point ]
<P>
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>venus</B> manages a cache of files and directories for a client workstation. It has a host of parameters and configuration options. Default values of everything are compiled into <B>venus</B> (see <EM><venus.private.h>) for these values</EM>. Some of these are overridden by the values in the <EM>vstab</EM>(5), provided that it exists. Both default and vstab values may be overridden with command-line arguments. Venus must be run as root.
<P>The command-line options are:
<DL>
<DT><B><B>-k</B> <EM>kernel device</EM></B><DD><P>Take <EM>kernel device</EM> to be the device for kernel/venus communication.
<P>Default: <EM>/dev/cfs0</EM>
<P>
</DL>
<DL>
<DT><B><B>-h</B> <EM>host list</EM></B><DD><P>Take comma-separated <EM>host list</EM> to be the initial set of hosts to be used for volume-location requests.
<P>
</DL>
<DL>
<DT><B><B>-cf</B> <EM>cache files</EM></B><DD><P>Limit the size of the file cache to <EM>cache files</EM> entries.
<P>Default: <EM>512</EM>
<P>
</DL>
<DL>
<DT><B><B>-c</B> <EM>cache blocks</EM></B><DD><P>Limit the size of the file cache to <EM>cache blocks</EM> 1K blocks.
<P>Default: <EM>8192</EM>
<P>
</DL>
<DL>
<DT><B><B>-mles</B> <EM>CML entries</EM></B><DD><P>Number of Cache Modify Log entries
<P>
</DL>
<DL>
<DT><B><B>-vols</B> <EM>volumes</EM></B><DD><P>Limit the size of the volume cache to <EM>volumes</EM> entries.
<P>Default: <EM>128</EM>
<P>
</DL>
<DL>
<DT><B><B>-vsgs</B> <EM>vsgs</EM></B><DD><P>Limit the size of the VSG cache to <EM>vsgs</EM> entries.
<P>Default: <EM>64</EM>
<P>
</DL>
<DL>
<DT><B><B>-d</B> <EM>debug level</EM></B><DD><P>Initialize the debug level to <EM>debug level</EM>. Meaningful values are {0, 1, 10, 100, 1000}.
<P>Default: <EM>0</EM>
<P>
</DL>
<DL>
<DT><B><B>-r</B> <EM>root volume</EM></B><DD><P>Take <EM>root volume</EM> to be the root volume of the file system. This should be a string name rather than a number. There is no default. If no value is given, venus will ask one of the file servers. [N.B. If you intend to operate disconnected, a value must be supplied.]
<P>Default: <EM>none</EM>
<P>
</DL>
<DL>
<DT><B><B>-f</B> <EM>cache directory</EM></B><DD><P>Take <EM>cache directory</EM> to be the directory for the file, volume, and VSG caches. Venus garbage collects any files it doesnt recognize in the cache directory, so use caution when supplying this argument. Venus will create the directory if it doesnt already exist. The directory should have mode bits of <EM>rwx------</EM> to protect the cache from malicious local users.
<P>Default: <EM>/usr/coda/venus.cache</EM>
<P>
</DL>
<DL>
<DT><B><B>-m</B> <EM>COP modes</EM></B><DD><P>Controls what Coda Optimistic Protocol (COP) options are enabled. <EM>COP modes</EM> is interpreted according to the following bit-mask: [ PIGGYCOP2 | ASYNCCOP2 | ASYNCCOP1 ]. Only some combinations are legal.
<P>Default: <EM>[ PIGGYCOP2 | ASYNCCOP2 ]</EM>
<P>
</DL>
<DL>
<DT><B><B>-mc</B> <EM>0 | 1</EM></B><DD><P>Controls whether multicast is used or not (0
<P>
</DL>
<DL>
<DT><B><B>-console</B> <EM>console file</EM></B><DD><P>Redirects console messages to <EM>console file</EM>.
<P>Default: <EM>/dev/console</EM>
<P>
</DL>
<DL>
<DT><B><B>-retries</B> <EM>RPC2 retries</EM></B><DD><P>Sets the number of RPC2 retries to <EM>RPC2 retries</EM>.
<P>Default: <EM>4</EM>
<P>
</DL>
<DL>
<DT><B><B>-timeout</B> <EM>RPC2 timeout</EM></B><DD><P>Sets the RPC2 timeout period to <EM>RPC2 timeout</EM> seconds.
<P>Default: <EM>30</EM>
<P>
</DL>
<DL>
<DT><B><B>-ws</B> <EM>SFTP window size</EM></B><DD><P>Sets the SFTP window size to <EM>SFTP window size</EM> packets.
<P>Default: <EM>8</EM>
<P>
</DL>
<DL>
<DT><B><B>-sa</B> <EM>SFTP send ahead</EM></B><DD><P>Sets the SFTP send ahead to <EM>SFTP send ahead</EM> packets.
<P>Default: <EM>4</EM>
<P>
</DL>
<DL>
<DT><B><B>-ap</B> <EM>SFTP ack point</EM></B><DD><P>Sets the SFTP ack point to <EM>SFTP ack point</EM> packets.
<P>Default: <EM>4</EM>
<P>
</DL>
<DL>
<DT><B><B>-init</B></B><DD><P>Initializes LEFTPAREN i.e., clears) file, volume, and VSG caches.
<P>
</DL>
<DL>
<DT><B><B>-p</B></B><DD><P>Enables profiling.
<P>
</DL>
<DL>
<DT><B><B>-hdbes</B> <EM>hoard entries</EM></B><DD><P>Number of hoard database entries.
<P>
</DL>
<DL>
<DT><B><B>-rvmt</B> <EM>RVMT type</EM></B><DD><P>Media that RVM resides on. Meaningful values are: 1
<P>
</DL>
<DL>
<DT><B><B>-sim</B> <EM>infile outfile filtfile systype</EM></B><DD><P>Turn on simulator mode. <EM>infile</EM> is a trace to load in to the simulation. <EM>outfile</EM> is the output file for the simulation. <EM>filtfile</EM> is a filter for the trace. And <EM>systype</EM> is the system type the trace was taken on.
<P>
</DL>
<DL>
<DT><B><B>-mondhost</B> <EM>hostname</EM></B><DD><P>Host where <EM>mond</EM> database is stored
<P>
</DL>
<DL>
<DT><B><B>-mondportal</B> <EM>port</EM></B><DD><P>Port to use when contacting the <EM>mond</EM> host.
<P>
</DL>
<DL>
<DT><B><B>-maxprefetchers</B> <EM>fetch threads</EM></B><DD><P>Maximum number of threads doing prefetch ioctls
<P>
</DL>
<DL>
<DT><B><B>-maxworkers</B> <EM>work threads</EM></B><DD><P>Number of worker threads.
<P>
</DL>
<DL>
<DT><B><B>-maxcbservers</B> <EM>cb threads</EM></B><DD><P>Number of callback server threads.
<P>
</DL>
<DL>
<DT><B><B>-vld</B> <EM>device</EM></B><DD><P>Location of the venus log device.
<P>Default: <EM>/usr/coda/LOG</EM>
<P>
</DL>
<DL>
<DT><B><B>-vlds</B> <EM>size</EM></B><DD><P>Size of the log device.
<P>
</DL>
<DL>
<DT><B><B>-vdd</B> <EM>device</EM></B><DD><P>Location of the venus data device.
<P>Default: <EM>/usr/coda/DATA</EM>
<P>
</DL>
<DL>
<DT><B><B>-rdscs</B> <EM>chunk size</EM></B><DD><P>Specify RDS chunk size.
<P>
</DL>
<DL>
<DT><B><B>-rdsnl</B> <EM>nlists</EM></B><DD><P>Number of RDS nlists.
<P>
</DL>
<DL>
<DT><B><B>-logopts</B> <EM>0 | 1</EM></B><DD><P>Turn on log optimization.
<P>
</DL>
<DL>
<DT><B><B>-swt</B> <EM>weight</EM></B><DD><P>Short term cache priority weight.
<P>
</DL>
<DL>
<DT><B><B>-mwt</B> <EM>weight</EM></B><DD><P>Medium term cache priority weight.
<P>
</DL>
<DL>
<DT><B><B>-ssf</B> <EM>scale factor</EM></B><DD><P>Short term cache scale factor.
<P>
</DL>
<DL>
<DT><B><EM>mount point</EM></B><DD><P>Directory to serve as the mount point for Coda.
<P>Default: <EM>/coda</EM>
<P>
</DL>
<P>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>Venus writes debugging information into the file <cache directory>/venus.log. The verbosity of this output is controlled by the <debug level> parameter. High priority messages are also written to the console (which may be redirected with the console option at start-up). Fatal errors will cause the internal state of venus to be dumped to the log file, and a core file to be left in <cache directory/core>.
<P>Venus writes its process id into the file <cache directory>/pid. The vutil (8v) program reads the pid file and dynamically alter Venus behavior by sending signals to it.
<P>Venus may be unable to unmount itself cleanly when it exits. Usually this is due to processes which have references to vnodes in the Coda namespace (e.g., a process is cded somewhere in Coda). Once these references are released, Venus can be unmounted with cfsunmount (8v).
<P>
<P>
<P>
FILES
<H3></H3>
<P><EM>/usr/coda/etc/vstab</EM>
<P><EM><cache directory>/venus.log</EM>
<P><EM><cache directory>/pid</EM>
<P><EM><venus.private.h></EM>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>A mount point of <EM>/coda</EM> is assumed by the pioctl library.
<P>A cache directory of <EM>/usr/coda/venus.cache</EM> is assumed by vutil (8v).
<P>
<P>
SEE ALSO
<H3></H3>
<P>vstab (5), cfsunmount (8v), vutil (8v)
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>Joshua Raiff, 1993, Documented added switches
<P>
<P>
<P>
<P>
<P>
\newpage
<H2><A NAME="ss19.53">19.53 volutil(8) </A>
</H2>
<P>
<P>
<P>
NAME
<H3></H3>
<P>volutil - volume utility subsystem
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P>volutil [-h <server>] [ -t timeout]
[ -d debuglevel] <command>
<parameters ... >
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>Volutil</B> is a RPC interface to the volume utility subsystem of the
file server. The volume utilities are used to perform administrative
functions like creating, cloning, purging, dumping and restoring volumes.
Each of these functions can be invoked via the <B><command></B>
parameter. Each command has a set of parameters that it expects. These are
listed below along with a short description of each command. The volutil
utility may be instructed to perform the operations on a server at a remote
site by specifying the server to which to connect with the -h option.
The default is to connect to a server on the local machine. The -t option
may be used to specify the timeout (in seconds) to be used by RPC2.
<P>
<DL>
<DT><B><B>ancient</B> <EM><group-ID></EM> <EM><rep-ID></EM></B><DD><P>Tell the server that backup succeeded for this volume. The next dump of this
volume, if incremental, will be based on the state represented by this backup.
The input should be in Hex.
<P>
</DL>
<P>
<DL>
<DT><B><B>backup</B> <EM><volume-ID></EM></B><DD><P>Create a backup
clone of a read/write volume. If a backup clone already exists,
update it to reflect the current state of the read/write volume;
Otherwise, create a new read-only volume. The read/write volume must
be locked for this to succeed. Backup unlocks the volume as a side effect.
<P>
</DL>
<P>
<DL>
<DT><B><B>clone</B> <EM>volume-ID</EM> [-n <EM>new-volume-name</EM>]</B><DD><P>Create a read only clone of a read write volume with (replica) ID
(<EM><volume-ID></EM>). The vnodes are actually copied but the inodes
are marked copy-on-write i.e. inodes need to be copied only if modified.
The name of the new cloned volume can be optionally specified by the
<EM><new-volume-name></EM> parameter. Default value is
volume-name.readonly. The <EM>clone</EM>(8) command can be used to call
<B>volutil clone</B>.
<P>
</DL>
<P>
<DL>
<DT><B><B>create</B> <EM><partition-path></EM> <EM><volume-name></EM></B><DD><P>Create a nonreplicated read-write volume named
<EM><volume-name></EM> on partition named
<EM><partition-path></EM>. The <EM>createvol</EM>(8) command
is a simplified front-end for this option.
<P>
</DL>
<P>
<DL>
<DT><B><B>create_rep</B> <EM><partition-path></EM>
<EM><volume-name></EM> <EM><group-ID></EM></B><DD><P>Create a
replicated read-write volume named <EM><volume-name></EM> on partition
named <EM><partition-path></EM>. The <EM><group-ID></EM>
parameter is used to specify the ID of the replicated volume to which this
replica will belong. The <EM>createvol_rep</EM>(8) command will also
create a replicated volume.
<P>
</DL>
<P>
<DL>
<DT><B><B>dump</B> [-i] <EM><volume-ID></EM>
<EM><file-name></EM></B><DD><P>Dump the entire contents of a volume
(<EM>volume-ID</EM> in Hex) to a file (<EM>file-name</EM>). If the -i flag
is used, the dump will be incremental, it will only include vnodes which have
been modified since the last dump was taken. The dump is not machine
independent, certain fields in the Vnode are not translated to network order.
However, dump files can be used to create restored volumes on machines with a
similar byte-order.
<P>
</DL>
<P>
<DL>
<DT><B><B>dumpmem</B> <EM><file-name></EM> <EM><address></EM> <EM><size></EM></B><DD><P>Dump <EM><size></EM> bytes starting at <EM><address></EM> into <EM><file-name></EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>elapse</B> <EM><on | off> <resolution | cb | mond | volDump> [MultiRPC]</EM></B><DD><P>Turn on or off timers for the given subsystem.
<P>
</DL>
<P>
<DL>
<DT><B><B>info</B> [-all] <EM><volume-name |
volume-number></EM> <EM><file-name></EM></B><DD><P>Print in ascii the
contents of a volume into a file (<EM><file-name>)</EM>. The volume can
be specified by its name, or by the volume-ID, specified in Hex. If -all is
specified, contents of both large and small vnodes in that volume are also
printed.
<P>
</DL>
<P>
<DL>
<DT><B><B>lock</B> <EM><volume-ID></EM></B><DD><P>Lock a volume to prevent write access to the volume. To other users
it will appear as if the operation would time out.
<P>
</DL>
<P>
<DL>
<DT><B><B>lookup</B> <EM><volume-name | volume-ID></EM>
<EM><file-name></EM></B><DD><P>Print information about a volume (specified
by <EM>volume-name</EM> or <EM>volume-ID</EM> specified in Hex) in
<EM>file-name</EM>. Only meta-information, such as replicated group-ID,
location, etc. is printed.
<P>
</DL>
<P>
<DL>
<DT><B><B>makevldb</B> <EM><VolumeList></EM></B><DD><P>Create a new Volume
Location Database <B>VLDB</B>. <EM>VolumeList</EM> names a file containing
volume parameters for all volumes in the system. This command typically is
run on the system control machine. See also <EM>bldvldb</EM>(8)
and <EM>volumelist</EM>(5).
<P>
</DL>
<P>
<DL>
<DT><B><B>makevrdb</B> <EM><vrlist></EM></B><DD><P>Create a new Volume
Replication Data Base (<B>VRDB</B>). <EM><vrlist></EM> is a file
containing entries describing replicated volumes. Each entry contains the
name, group-ID, read-write ids, and the VSG address of a replicated volume.
There is one entry per replicated volume in the system.
<P>
</DL>
<P>
<DL>
<DT><B><B>purge</B> <EM><volume-ID></EM> <EM><volume-name></EM> </B><DD><P>Delete a volume. For replicated volumes <B>purge</B> must be called
from each server individually on the replicas at the different servers. (See
purgevol-rep(8))
<P>
</DL>
<P>
<DL>
<DT><B><B>restore</B> <EM><file-name></EM>
<EM><partition-path></EM> [<EM><volume-ID></EM>
<EM><volume-name></EM>]</B><DD><P>Create a new volume on the partition
named by <EM><partition-path></EM> and read in the contents from a dump
in file <EM><file-name></EM>. The new volume will be given the name and
ID specified on the command line. If either is unspecified, or if the Volume
ID is of illegal form, the server will allocate the ID or name based on
internal rules. The volume-ID should be specified in Hex.
<P>
</DL>
<P>
<DL>
<DT><B><B>rvmsize</B> <EM><volume-ID></EM></B><DD><P>Print the RVM
statistics for the volume <EM><volume-ID></EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>setdebug</B> <EM><level></EM></B><DD><P>Set the debug level for the volume and directory packages to <EM>level</EM>.
To reset it use zero for the <EM>level</EM> argument. The rpc2 debug level is set to level/10.
<P>
</DL>
<P>
<DL>
<DT><B><B>setlogparms</B> <EM><volume-ID></EM>
[<EM><reson></EM> <1 | 0>]
[<EM><logsize></EM> <EM><size></EM>]</B><DD><P>Turn on
resolution or change the log size for a volume. The volume ID can be either
the replicated ID or the non-replicated ID. Resolution is turned on by
specifying 4 after <EM>reson</EM> and can be turned off by specifying 0. The
size of the log can also be changed for the volume. The <EM>size</EM>
parameter refers to the number of maximum entries in the log. This should be
a multiple of 32. Typically this is set to 8192.
<P>
</DL>
<P>
<DL>
<DT><B><B>setvv</B> <EM><volumeNumber></EM> <EM><vnodeNumber></EM>
<EM><Uniquifier></EM> <EM><version numbers (8)</EM>> <EM><host
unique flags></EM></B><DD><P>Set the version vector for a vnode (with fid =
<EM><volumeNumber>.<vnodeNumber>.<Uniquifier></EM>).
The new version vector is specified by the <EM><version numbers></EM>
and the <EM><host unique flags></EM> triple.
<P>
</DL>
<P>
<DL>
<DT><B><B>showvnode</B> <EM><volumeNumber></EM>
<EM><vnodeNumber></EM> <EM><Uniquifier></EM>
<EM><file-name></EM></B><DD><P>Print the contents of a vnode (with
fid = <EM><volumeNumber>.<vnodeNumber>.<Uniquifier></EM>).
into <EM><file-name></EM>.
<P>
</DL>
<P>
<DL>
<DT><B><B>shutdown</B></B><DD><P>Bring all volumes offline and bring down the
server.
<P>
</DL>
<P>
<DL>
<DT><B><B>swaplog</B></B><DD><P>Save the fileserver log output
(in <EM>SrvLog.old</EM>) and start a new SrvLog.
<P>
</DL>
<P>
<DL>
<DT><B><B>timing</B> <EM>on | off <filename></EM></B><DD><P>Turn timing on or off.
<P>
</DL>
<P>
<DL>
<DT><B><B>truncatervmlog</B></B><DD><P>Forcibly truncate the RVM log.
<P>
</DL>
<P>
<DL>
<DT><B><B>unlock</B> <EM><volume-ID></EM></B><DD><P>Unlock a volume
locked via the <B>volutil</B> lock command. (<EM>volume-ID) should be in
Hex</EM>
<P>
</DL>
<P>
<DL>
<DT><B><B>updatedb</B></B><DD><P>Make the file server read in a new VLDB and VRDB.
The server assumes the databases to exist in <EM>/vice/db/VLDB</EM> and
<EM>/vice/db/VRDB</EM>. This utility is useful for reading in new databases
at non-scm machines.
<P>
</DL>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>This command must be run as root. It works only on the machine running
the server. Also, the token file <EM>/vice/db/voutil.tk</EM> must be
accessible.
<P>
<P>
BUGS
<H3></H3>
<P>The salvage option to volutil doesn't work right. Please don't try it.
<P>
<P>
FILES
<H3></H3>
<P><EM>/vice/db/VSGDB</EM>
<P><EM>/vice/file/SrvLog</EM>
<P><EM>/vice/db/VLDB</EM>
<P><EM>/vice/db/VRDB</EM>
<P><EM>/vice/vol/VRList</EM>
<P>
<P>
SEE ALSO
<H3></H3>
<P>vrdb(5), volumelist(5), bldvldb(8), createvol(8), createvol_rep(8),
purgevol(8), purgevol_rep(8)
<P>
<P>
AUTHOR
<H3></H3>
<P>Puneet Kumar, David Steere, 1990, Created
<P>
<P>
\newpage
<H2><A NAME="ss19.54">19.54 vutil(8) </A>
</H2>
<P>
<P>
NAME
<H3></H3>
<P>vutil - venus utility program
<P>
<P>
<P>
SYNOPSIS
<H3></H3>
<P><B>vutil</B> [-cop COP modes] [ -cs ]
[-d debug level] [-mc 0 | 1 ] [-p 0 | 1]
<P> [-shutdown] [-stats] [-swap]
<P>
<P>
<P>
DESCRIPTION
<H3></H3>
<P><B>vutil</B> dynamically alters various parameters on a running Venus. It
reads the value of the file /usr/coda/venus.cache/pid and sends signals to
that process.
<P>The parameters are:
<DL>
<DT><B><B>-cop</B> <EM>COP modes</EM></B><DD><P>Controls what Coda Optimistic
Protocol (COP) options are enabled. <EM>COP modes</EM> is interpreted
according to the following bit-mask: [PIGGYCOP2 | ASYNCCOP2 | ASYNCCOP1
]. Only some combinations are legal.
<P>
</DL>
<P>
<DL>
<DT><B><B>-cs</B></B><DD><P>Clears internal counters used in statistics reporting.
<P>
</DL>
<P>
<DL>
<DT><B><B>-d</B> <EM>debug level</EM></B><DD><P>Sets the debug level to <EM>debug
level</EM>. Meaningful values are {0, 1, 10, 100, 1000}.
<P>
</DL>
<P>
<DL>
<DT><B><B>-mc</B> <EM>0 | 1</EM></B><DD><P>Enable/disables multicast
(0 = ``OFF,'' 1 = ``ON'')
<P>
</DL>
<P>
<DL>
<DT><B><B>-p</B> <EM>0 | 1</EM></B><DD><P>Enables/disables profiling
(0 = ``OFF,'' 1 = ``ON'')
<P>
</DL>
<P>
<DL>
<DT><B><B>-shutdown</B></B><DD><P>Shuts Venus down gracefully.
<P>
</DL>
<P>
<DL>
<P>
<DT><B><B>-stats</B></B><DD><P>Causes Venus to dump internal counters and other
statistics to its log file.
<P>
</DL>
<P>
<DL>
<DT><B><B>-swap</B></B><DD><P>Causes Venus to move its current log
file to <log-file>.old and reinitialize <log-file>.
<P>
</DL>
<P>
<P>
DIAGNOSTICS
<H3></H3>
<P>Only the super user can run <B>vutil</B>.
<P>
<P>
FILES
<H3></H3>
<P><EM>/usr/coda/venus.cache/pid</EM>
<P><EM>/usr/coda/venus.cahe/venus.log</EM>
<P>
<P>
<P>
BUGS
<H3></H3>
<P>Venus cache directory is assumed to be <EM>/usr/coda/venus.cache</EM>.
<P>
<P>
<P>
SEE ALSO
<H3></H3>
<P>venus LEFTPAREN 8)
<P>
<P>
<P>
AUTHOR
<H3></H3>
<P>Jay Kistler, 1990, Created
<P>
<P>
<HR>
Next
<A HREF="manual-18.html">Previous</A>
<A HREF="manual.html#toc19">Contents</A>
</BODY>
</HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
36
