Next Previous Contents

19. Unix Manual Pages


19.1 cfs(1)


cfs - Coda File System Interface Program


cfs bandwidth <speed>

cfs checkpointml

cfs checkservers

cfs checkvolumes

cfs clearpriorities

cfs compress <file> [<file> <file> ...]

cfs [@cpu|@sys] cfs disconnect

cfs endrepair <file>

cfs examineclosure

cfs flushcache

cfs flushobject <obj> [<obj> <obj> ...]

cfs flushvolume <dir> [<dir> <dir> ...]

cfs getfid <path> [<path> <path> ...]

cfs getpath <fid> [<fid> <fid> ...]

cfs getmountpoint <volid>

cfs listacl <dir> [<dir> <dir> ...]

cfs listcache [<dir> <dir> ...]

cfs listvol <dir> [<dir> <dir> ...]

cfs lsmount <dir> [<dir> <dir> ...]

cfs mkmount <directory> <volume name> [-rw]

cfs purgeml

cfs reconnect

cfs replayclosure

cfs rmmount <dir> [<dir> <dir> ...]

cfs setacl [-clear] [-negative] <dir> <id> <rights> [<id> <rights> ....]

cfs slow <speed (bps)>

cfs truncatelog

cfs uncompress <file> [<file> <file> ...]

cfs waitforever [-on] [-off]

cfs whereis <dir> [<dir> <dir> ...]

cfs writedisconnect [-age <secs> -time <secs> <dir> ]

cfs writereconnect [<dir> <dir> ...]


cfs 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. cfs will change the protection or "rights" on directories but not on individual files. To change permissions on individual files, use chmod (1).


Provide a hint about network speed. Use this command to tell venus your networks speed in bits per second.

Abbreviation: bw.


Checkpoint volume modify log. This command will create a checkpoint file /usr/coda/spool/<uid>/<vol>@<mountpt>. Where <uid> is your cfs user id, <vol> is the volume being checkpointed, and <mountpt> is the volume's mount point.

Abbreviation: ck.


Check the status of the Coda file servers. Report on servers that are down.


Check volume/name mappings.


Clear short-term priorities used for cache management.


compress given files in the cache. these files will be uncompressed automatically if they are touched or can be explicitely uncompressed with the cfs uncompress command.

@cpu or @sys

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.


Partition your client from the Coda file servers.


Tell venus to end a repair session on file. Useful if repair is exits without finishing the repair session.

Abbreviation: er.


Examine reintegration closure. Using cfs examineclosure will display the fixfile used to reintegrate changes that were made while operating in disconnected mode.

Abbreviation: ec


Flush entire cache. Care must be taken when using the cfs flushcache command, as flushing the cache while operating in disconnected mode may result in loss of data.


Flush objects from cache. cfs flushobject tells venus to remove the given objects from the cache.

Abbreviation: fl


Flush all data in specified volumes. Care must be taken when using the cfs flushvolume command, as flushing the cache while operating in disconnected mode may result in loss of data.


Map the given paths to Coda file ids.

Abbreviation: gf


Map fid to volume-relative path. cfs getpath will display the path for each of the given fids.

Abbreviation: gp


List access control list for each of the given directories.

Abbreviation: la


List the contents of the entire cache or the given volumes (directories).

Abbreviation: lc


Display the current status of the volume in which the directory is stored.

Abbreviation: lv


List the countents of a mount point. This command can be used to tell what volume a mount point refers to.


Create a mount point. Mount volume name at the point in the file system described by filename. If the -rw 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.

Abbreviation: mkm


Purge volume modify log. Care must be taken when using the cfs purgeml command, as it may result in loss of data.


Reconnect to the Coda file servers. cfs reconnect will undo the effects of a cfs disconnect.


Replay reintegration closure.

Abbreviation: rc


Remove a mount point from the file system. The volume itself is not changed.

Abbreviation: rmm


Set access control list. Sets the access control list for each id. The -clear switch clears the access control list except for the entries given on the call to cfs. The -negative switch denies the given permissions, rather than granting them. Rights are a subset of rwidlak which are read, write, insert, delete, lookup, administer, and lock respectively. See the section on File Protection in the Coda manual for more detail.

Abbreviation: sa


Set network speed to the given speed in bits per second.


Truncate the RVM log at this instant.

Abbreviation: tl


Uncompress given cached files. venus will automatically uncompress any compressed files that it touches in the cache.


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.

Abbreviation: wf


List the servers that the given files reside on.


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.

An -age argument gives the age of the CML before it should be reintegrated. The -time arguments gives the number of seconds the sending of a reintegration fragment should take. Abbreviation: wd


Strongly connect to the servers.

Abbreviation: wr


chmod (1)


1987, Adapted from AFS-2s fs

Maria R. Ebling, 1990, Created man page

M. Satyanarayanan, 1992, cfs rewritten from scratch

Joshua Raiff, 1993, Man page rewritten

Joshua Raiff, 1995, Updated


19.2 clog(1)


clog - Authenticate yourself to the Coda file system


clog [[-x] user [ password ] ]


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 Authentication Server. The Authentication Server returns a set of tokens encoding the chosen identity if the password is correct. clog passes these tokens to the venus 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 Anonymous user.

clog accepts the following arguments:


Login name you wish to be identified as.


Password corresponding to the given user name. (If not provided on the command line, the user will be prompted for one.)


The -x switch is not needed. Specifying a username and passwd is sufficient.


cunlog (1), venus (8)


1987, Adapted from AFS-2

Maria R. Ebling, 1990, Created man page


19.3 cmon(1)


cmon - Coda server monitor


cmon [-a] [-t probeinterval] server1:hz1 server2:hz2 ......


cmon probes the specified list of servers once every probeinterval seconds and reports on their status. If a server is down or unreachable, cmon tries to reestablish contact with it once every probeinterval seconds. It uses the curses (3) package for screen management and can be used on dumb terminals. Run cmon in a terminal emulator (like xterm) if you are using a window manager (like X).

Hz1, hz2, etc. are the values of the kernel constant HZ 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.

Some cmon 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. cmon can be toggled between absolute and real modes of presentation from the keyboard. Typing a will cause data to be presented in absolute mode. Typing r will present it in relative mode. A mode change will only take place at the next probe.

The command-line options are:


Report data in absolute mode.

-t probeinterval

Probe servers every probeinterval seconds. Default is 60.

The data reported by cmon is organized under four headings: TIM, CPU, RPC, and DSK.

The TIM data is as follows:


time at which this cmon process was created.


time at which the server was last probed.


time at which the server last responded to a probe.


time at which the server process was started.


number of times contact was reestablished after a failed probe. A probe may fail due to server or network failures.

The CPU data is as follows:


relative or absolute number of seconds of system CPU time used on the server.


relative or absolute number of seconds of user CPU time (regular or niced) used on the server.


relative or absolute number of system and user seconds divided by corresponding time of accumulation.

The RPC data is as follows:


number of RPC connections.


number of workstations connected to server. Note that each instance of cmon shows up as a workstation.


relative or absolute number of RPC calls received.


relative or absolute number of RPC packets received. Includes duplicates and other bogus packets. Also includes bulk transfer packets.


relative or absolute number of packets sent. Includes retransmissions. Also includes bulk transfer packets.


bytes corresponding to pki.


bytes corresponding to pko.

The DSK data is as follows:


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.


identity and percent usage of second most full disk.


identity and percent usage of third most full disk.


If a server is down or unreachable, statisitics for it are reported as "???".

Relative data is undefined until two or more probes have been made. Such data is reported as "***" between the very first and second probes.


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.

The display is optimized for maximum packing of information into a small screen area. It may be cryptic for a novice.

No disk information is available about the root partition on a server.

Will core dump if run in a window with fewer than 25 lines.

No way to force a redisplay (eg ^L).


vutil (8), curses (3), codacon (1)


M. Satyanarayanan, 1990, Created


19.4 cpasswd(1)


cpasswd - change Coda login password


cpasswd [-h host] [username]


This command sets the password associated with the current user, or user username if explicitly named. Only the user or a System Administrator may change a password.

cpasswd 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.

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.

cpasswd 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 AuthServers.

cpasswd support the following option:

-h host

Tells cpasswd which authentication host to bind to. This should be the SCM.




The password file information should be kept in a different data structure allowing indexed access; dbm (3X) would probably be suitable.


clog (1), crypt (3)


1987, Adapted from AFS-2

Maria R. Ebling, 1990, Created man page


19.5 ctokens(1)


ctokens - list all tokens




The ctokens command enables users to query Venus for information about the set of authentication tokens it holds for the user. The ctoken command prints out the ID of the current user and whether or not the user is currently authenticated.


If authenticated as another user, ctokens will say that you own the token.


clog (1), login (1), su (1), cunlog (1)


1987, Adapted from AFS-2s unlog

David C. Steere, 1990, Created man page


19.6 cunlog(1)


cunlog - Tell the Coda Venus to release authentication tokens




This command enables a user to inform the Coda Cache Manager, Venus, 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 clog.


login (1), su (1), clog (1), ctokens (1)


1987, Adapted from AFS-2s unlog

David Steere, 1990, Created man page


19.7 filcon(1)


filcon - the RPC2 filter control utility.



filcon isolate -s srv1 [srv2 ... ] -c clnt1 [clnt2 ....]

filcon join -s srv1 [srv2 ... ] -c clnt1 [clnt2 ....]

filcon clear -s srv1 [srv2 ... ] -c clnt1 [clnt2 ....]

filcon partition -s srv1 -c clnt1

filcon heal -h hostname1 port1 -h hostname2 port2

filcon oldpartition -h hostname1 port1 -h hostname2 port2

filcon slow -h hostname1 port1 -h hostname2 port2

filcon help


filcon 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.

The Coda failure emulation package consists of two pieces: a library of routines (libfail) that is linked in with each client and server, and a user interface program (filcon) 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.

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 send filters, or source for receive filters) is used to determine what action should be taken on the packet.

A filter consists of three parts: a probability, a predicate, and a delay. The probability specifies what fraction of packets that match the predicate are allowed to pass through unharmed. The delay 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 incoming (receive) packets or outgoing (send) packets.

filcon enables a user to manipulate filters. There are two modes of operating with filcon: short summary command line commands, and interactive use. The interactive user interface presented by filcon is based on the readline (3) and Coda parsing libraries. A command with arguments can be issued in two ways. If only the command name is typed, filcon 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.


Start this mode by typing filcon.

The following commands are available.

addclient host port

Connects to a client at IP port number port on the host named host. (For Coda clients and servers, use 1363 and 1361 respectively.)

deleteclient clientnum

Disconnects from; client number clientnum.


Lists the current set of connected clients.

insertfilter clientnum side id host color lenmin lenmax probability speed

Inserts a filter into client number clientnum's table on the specified side (one of in out). The filter will be inserted after the existing filter with identifier id. (Inserting after the filter with identifier 0 will insert the filter before all existing filters.) The characteristics of the new filter are host, color, lenmin, lenmax, probability and speed. Host 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. Lenmin and lenmax specify the minimum and maximum RPC packet sizes that match this filter. Color 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 receive filters.

removefilter clientnum side id

Removes the filter with identifier id on the given side of client clientnum.

getfilters clientnum

Lists the filters at client clientnum.

purgeFilters clientnum side

Removes all filters from the set specified by side. side can be either in, out, or both (the default).


Terminates the program. Note that this does not clear any filters.


filcon isolate

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.

filcon join

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.

filcon clear

Removes all filter from the hosts given.


blocks traffice between the hosts given.


removes all of the filters between hostname1 and hostname2 inserted by partition, or slow, or filcon.


inserts filters on hostname1 and hostname2 to control the network speed between the machines.



Port to attatch to. This should be 1363 for a Coda client and 1361 for a server.


Speed in bits per second


You cannot currently designate a host by IP address of the form a.b.c.d as described above when binding to a process.

May confuse the user with the error message ``RPC2_SUCCESS.''

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.


Walter Smith, 1988, created. M. Satyanarayanan, 1990, updated. Puneet Kumar, 1990, Created Maria R. Ebling, 1991, updated. Lily Mummert, 1992, Added support for speed. David Steere, 1994, Added "purgeFilters", slight rewrite. Joshua Raiff, 1993, Created man page

Peter Braam, 1998, Complete rewrite for filcon.


19.8 hoard(1)


hoard - hoard database front-end


hoard [ -d ] [ -f source | cmds ]


Hoard is a front-end to the hoard database (HDB) managed by the Coda cache manager, Venus. 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.

Users manipulate the HDB by issuing commands to the hoard program. The following hoard commands are currently recognized:

add filename <attributes>

clear <uid>

delete filename

list outfile <uid>

modify filename <attributes>

Hoard distinguishes between children of a directory, which are members of the directory, descendants which are either children or descendants of childres of the directory.

Commands may be abbreviated by their first letter. Parameters in angle brackets are optional, and have default values if unspecified. The attributes parameter is specified as a string of options separated by : characters. The currently recognized options are:


assign this object the hoard priority indicated


current children of this directory will inherit its hoard status


current and future children of this directory will inherit its hoard status


current descendents of this directory will inherit its hoard status


current and future descendents of this directory will inherit its hoard status

If the uid in the clear and list commands is unspecified, the entries of all users are cleared or listed respectively. The default hoard priority is 10.

An example command file is:


add /coda/project/coda/src 100:d+

add /coda/usr/jjk/.login 1000

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 primary 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.

The command-line options are:


Enables debugging output.

-f source

Take commands from file source. -f must be the last argument if specified. An argument of - means use stdin as the source file. Source statements may be given directly on the command line (one per line) by enclosing them in single quotes.


Hoard copies command lines that it cannot parse to stderr. If a syntactically correct command is rejected by Venus, the corresponding pioctl, its arguments, and the errno are copied to stderr.


Negative priorities should be allowed.

A mount point of /coda is assumed by the pioctl library.


venus (8)


Jay Kistler, 1990, Created


19.9 mvdb(1)


mvdb - Atomically update files in a directory


mvdb [-l lockfile] file1 file2 ...


mvdb [-l lockfile] newfile1=file1 newfile2=file2 .....


mvdb 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 cd'd into the destination directory already. If you do not specify a lockfile, the current directory "." is locked. The Unix primitive flock() 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 newfile=file construct. If a file filename already exists in the directory, it is first renamed to filename.BAK. The dates of the target are copied from the source files.

The options are:


Verbose mode. Will print out information on the progress of the command.


Force update. Moves in the files even if the source files are not newer.


cd /itcbin/vice/bin
mvdb /usr/andrew/bin venus2.sun=venus2 file salvage 


All the files have to come from the same source directory.

You have to be cd'd into the target directory. You need Lock rights in Vice directories for locking.


Created: M.Satyanarayanan, 1985


19.10 repair(1)


repair - repair conflicts in the Coda file system


repair [-d]

repair [-allowclear]

repair [<object_in_conflict> <fix_file> <repair_options>]


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.

Repair uses the ci command interpreter to present its user interface or repair 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.

To use the repair tool interactively, type repair at the command prompt.

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 EXAMPLES section for examples on invoking complete repair sequences from the command line.

A description of the repair command follows:

beginrepair object

verifies that object 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.

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 comparedirs, dorepair and removeinc commands to repair the conflict.

For a local-global repair session, both local and global replicas of object are visible at object/local (read-only) and object/global (mutable and serving as the workspace for storing the repair result for object). You need to iterate through the current sessions local-mutations-list containing all the local updates to object and its descendants. Each operation in local-mutations-list must be accounted for and Venus maintains the current-mutation being iterated. Use the checklocal command to find out the conflict between the current-mutation and the server state. Note that not all local mutations are necessarily in conflict, and you can use the listlocal command to see all the operations in local-mutations-list. You can advance the iteration to the next operation using either the preservelocal or the discardlocal command with the former replaying the current-mutation operation on the relevant global replicas. To speed up the iteration, the preservealllocal command repeats preservelocal until the local-mutations-list is exhausted or the first replay failure. Similarly, the discardalllocal command repeats discardlocal until exhausting the local-mutations-list. You can use external tools such as emacs to make direct updates on needed replicas under object/global. Use the quit command to either commit or abort the session.


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.


prints out a help message.

Use the following commands to repair a server-server conflict:

comparedirs object fixfile [-acl <user> <rwlikda > ] [-mode <newmode> ] [-owner <username> ]

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 beginrepair on object and this command works only if object is a directory.

dorepair object fixfile

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 beginrepair on this object (or on on some other object in this volume.). If object is a file or symbolic link, fixfile must provide its new contents. If object is a directory, fixfile must provide a sequence of directory repair commands for each replica. The format of fixfile for directories is as follows:

    replica <servername> <id of replica1>
        <repair commands for replica1>
    replica <servername> <id of replica2>
         <repair commands for  replica2>
    and so on
Repair commands are given one per line. Blank lines are ok. id of replica1, id of replica2, 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 beginrepair command has succeeded. The directory repair commands are:
  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>
Note that for the setacl command, the short form access rights of all and none can also be used.

removeinc object

removes the inconsistent object 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.

clearinc object

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 comparedirs 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 dorepair command.

The following commands are used only for repairing local-global conflicts:


checks to see if the current-mutation 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 current-mutation 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 local-mutations-list.


simply advances the iteration of the local-mutations-list of the current local-global repair session to the next operation. Use this command when the user does not want the current-mutation operation to have any effect on the repair result.


tries to replay the current-mutation of the current local-global repair session on the relevant global replicas. In other words, it will try to preserve the effect of the current mutation in the repair result. If the replay succeeds, the iteration of local-mutations-list 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.


repeatedly performs the discardlocal command until the local-mutations-list is exhausted. Its effect is to finish the iteration and discard the effect of all the remaining mutations on the repair result.


repeatedly performs the preservelocal command until the first failure or the iteration of local-mutations-list is exhausted. This command is used if the user wants to preserve the effect of all the remaining mutation operations in the repair result.


prints out all the mutation operations in the local-mutations-list of the current local-global repair session.


If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, the global replica of object is visible at object/global. This command allows the global replica of object to be visible at the original location (pathname) of object.


If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, the local replica of object is visible at object/local. This command allows the local replica of object to be visible at the original location (pathname) of object.


If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, this command restore the default form of local-global conflict representation in which the local replica is visible at object/local and the global replica is visible at object/global.

The following commands existed in old versions but are no longer supported:

showreplicas object

shows the names of the individual replicas of object, and the pathnames by which these replicas may be examined read-only. A beginrepair must have been done earlier on this object (or on another object in the same volume).

unlockvolume pathname

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.


This will cause repair to examine the object "common", 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.

  repair common /tmp/fix -acl hmpierce all

The same repair would look like this in interactive mode:

repair> beginrepair common
repair> comparedirs common /tmp/fix -acl hmpierce all
repair> dorepair common /tmp/fix 
repair> endrepair
repair> quit


ci (3)


M. Satyanarayanan, 1989, Created

Puneet Kumar, 1991, Substantially revised

Joshua Raiff, 1993, Created man page

Qi Lu, 1995, Added local-global repair commands and revised man page

Henry M. Pierce, 1998, updated for command line options.


19.11 spy(1)


spy - Report all CFS files that are opened


spy [ -host <hostname> ] [ -uid <uid> ]


spy will connect to venus on the given host and report all Coda files that are opened. This is useful for generating hoard files as programs can have hidden dependencies. Using spy will ensure that any file that is opened gets included in the hoard database. Sending spy a SIGTERM will cause spy to flush all of its output buffers and terminate.

spy supports the following options:

-host hostname

Name of Coda coda client to bind to. If this option is omitted, then the current host will be used.

-uid uid

Only report on file activity from user uid. If the -uid switch is omitted, then all CFS file activity is reported.

To use spy to create a hoard file sort the output and remove any duplicates, By using spy you ensure that you did not forget to hoard a file with a hidden dependency. For example, when you hoard X, you will need the uncompress (1) program in order to use the fonts.


hoard (1)


Joshua Raiff, 1993, Created man page


19.12 venussetup(1)


venus-setup setup venus on a client


venus-setup [comma,separated,list,of,servers] [cachesize in kb]


The venus-setup command takes a list of servers separated by commas, one of which must be the SCM and a cache size given in kilobytes. NOTE: at least one server must be specified. And if only one server is specified, it must be the SCM for the Coda Cell. Venus-setup then performs the following operations:


Venus-setup Mickey,Minnie,Goofy 10000
Sets up, /usr/coda/etc/vstab, for venus to contact either Mickey, Minnie or Goofy and configures venus with a 10MB cache.


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.

Venus-setup will happily overwrite an existing, /usr/coda/etc/vstab, without warning.


/etc/services: the Internet network services list. /usr/coda/etc/vstab: the VenuS TABle specification file.


venus (8), vstab (5), services (5), servers (5)

Coda Manual: ``Installing A Coda Client''


Henry M. Pierce, 1998, created


19.13 vicesetup(1)


Vice-setup setup a Coda server




Vice-setup 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:

Is this the master server, aka the SCM machine? (y/n) 

Answering ``yes'' to this question causes the following sequence of scripts to be called from within vice-setup:

where as answering ``no'' causes only the following scripts to run from vice-setup:



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:


This script is only run if ``yes'' is given as an answer to the SCM question.


This script is only run by, vice-setup, when the machine is designated as the SCM.



This script sets up the data storage area for a Coda service.

For a detailed explanation of each question asked by the scripts, please see the chapter, ``Installing a Coda Server'' in the Coda Manual.


Many of the highlights are:


/vice/db/vicetab: the Vice Table Configuration file for srv.

/vice/vol/VolumeList: volumeList of the server.

/vice/db/scm: the SCM hostname.

/vice/hostname: the host's hostname.

/vice/srv.conf: the srv configuration file.






And many more files are touched by these scripts than are listed here.


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)

Coda Manual: ``Installing A Coda Server''

The RVM Manual


Henry M. Pierce, 1998, created


19.14 volmunge(1)

NAME volmunge - manipulates objects within Coda.

SYNOPSIS volmunge <-adfmov> dir


Prints out everything but does not cross volume boundaries.


Prints out UNIX directories, but not volume mount points.


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.


Prints out those objects which are volume mount points.


Prints out those objects which are UNIX files and preforms an open() call on the file.


Prints out the volume name of a volume's mount point.


volmunge: is ideal for identifying Coda objects versus regular UNIX files (including UNIX directories) stored within the Coda filesystem. It will work recursively.

Because the, -f and -o, 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.


find (1), perl (1)


Henry M. Pierce, 1998, created


19.15 histo(3)


histo - histogram package


#include <histo.h>

InitHisto (hg, lolimit, hilimit, bucketcount, ht)

struct hgram *hg;

double lolimit;

double hilimit;

int bucketcount;

enum htype ht;

UpdateHisto (hg, newval)

register struct hgram *hg;

double newval;

PrintHisto (outfile, hg)

FILE *outfile;

register struct hgram *hg;

PlotHisto (outfile, hg, graphtitle, xtitle, ytitle, psfileprefix)

FILE *outfile;

struct hgram *hg;

char *graphtitle;

char *xtitle;

char *ytitle;

char *psfileprefix;


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.

The package is used by calling the following routines:

InitHisto ()

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.

UpdateHist ()

updates the histogram hg with newvalue to be entered.

PrintHisto ()

provides the user with statistics for the input data. Statistics include the mean, standard deviation, and the 90% confidence interval.

PlotHisto ()

the output of this file is used as input to the program csplot to produce a histogram of the input data.


Negative return values indicate errors.


#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);



M.Satya, 1991


19.16 timing(3)


timing_paths - timing package


#include <timing_paths.h>

#include <histo.h>

#include <dtcreg.h>

ti_init ()

ti_create (nEntries, thistie)

int nEntries;

struct tie *thistie;

ti_notetime (thistie, id)

struct tie *thistie;

long id;

ti_postprocess (thistie, twrt)

struct tie *thistie;

enum timewrt twrt;

ti_discoverpaths (thistie, pinfo)

struct tie *thistie;

struct pths_info *pinfo;

ti_stat (thistie, pinfo)

struct tie *thistie;

struct pths_info *pinfo;

ti_destroy (thistie)

struct tie *thistie;

ti_end ()


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.

The package is used by calling the following routines:

ti_init ()

initialises the timer.

ti_create ()

allocates storage for n entries, where n corresponds to the total number of times ti_notetime () is called.

ti_notetime ()

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.

ti_postprocess ()

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).

ti_discoverpaths ()

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.

ti_stat ()

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.

ti_destroy ()

frees the storage used by the package.

ti_end ()

releases the timer.


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.


#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 ();


Gowthami Rajendran, 1991


19.17 backuplogs(5)


backuplogs.<DDMMMYY> - Format of a Coda backup log file


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:

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 merge(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.


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/
-7f0003f4.e10000bd ...
00:29:03                Transferred 112131 bytes

00:29:03 Dumping 7f0003f4.e30000ae to /backup1/05Jan1998/ ...
00:29:14                Transferred 3768325 bytes
01:12:12 Dumping 7f0003ef.e2000093 to /backup1/05Jan1998/ ...
01:18:31                Transferred 119182513 bytes

01:18:31 Dumping 7f0003ef.e10000a1 to /backup2/05Jan1998/ ...
01:33:44                Transferred 119182513 bytes

01:33:44 Dumping 7f0003ef.e3000092 to /backup3/05Jan1998/ ...
01:42:03                Transferred 119172268 bytes

03:58:16                Transferred 309842 bytes

03:58:19 Attempting to retry any failed operations.
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 Volumes that FAILED backup:
03:58:19 Volumes that were NOT backed-up:
03:58:19 0x7f000394                     t.test


---------> Partition /backup:
---------> command: mt -f /dev/nst0 rewind
---------> command: restore -b 500 -s 1 -f /dev/nst0 -t /
Level 0 dump of /backup on
Label: none
Dump   date: Mon Jan  5 04:05:14 1998
Dumped from: the epoch
         2      .
        11      ./lost+found
      2041      ./05Jan1998
      4081      ./05Jan1998/
      4082      ./05Jan1998/
      4087      ./05Jan1998/
      6121      ./05Jan1998/
      6122      ./05Jan1998/
      6127      ./05Jan1998/
      8161      ./05Jan1998/
      8162      ./05Jan1998/
      8167      ./05Jan1998/


backup (8), dump (1), restore (1), dumplist (5), vicetab (5), merge (8)


Joshua Raiff, 1993, Taken from the System Administrators Guide.

Henry M. Pierce, 1998, updated.


19.18 dumpfile(5)


dump file - Format of a dump file


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.

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.

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.

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.


backup (8), dumplist (5), volutil (8)


Joshua Raiff, 1993, Taken from system adminstrators guide.


19.19 dumplist(5)


dumplist - List of volumes to be archived by the Coda backup mechanism


The dumplist file contains information for the backup(8) program. It consists of a list of volumes to be archived.

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 backup 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.


The following does a full backup of coda_root, coda_root.i386, and coda_root.tmp on Monday while it does a full backup of coda_root.project and coda_root.usr on Wednesday. It uses /vicepa/backup and /usr/codabackup/backup to store the dump files.

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


In prior release of coda, the key words "Partition" and "Volumes" were used to distinguish between seperate sections of the dump file needed by backup. dumplist 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 backup reads vicetab for backup partition information.


backup (8), creatvol (8), createvol_rep (8), vicetab (5)


David C. Steere, 1991, Created updated 1998, hmp


19.20 groups.coda(5)


19.21 maxgrpid(5)


maxgroupid - replicated volume number allocation mechanism


The system control machine (SCM) has a file, /vice/vol/maxgroupid, 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.

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 /vice/vol/maxgroupid. For example, if you wish to use 7f000000 as the first replicated volume, create /vice/vol/maxgroupid with the number 2130706432.


/vice/vol/maxgroupid on the SCM


This file should be salvaged, but it is not.

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.


servers (5), createvol_rep (8)


Jay Kistler, 1990, Created


19.22 mcstagen(5)


multicastagents - multicastagents file specification


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:

  <agent address> <min allocation address> <max allocation address> <comments>

All addresses are in internet dot format (a.b.c.d). Allocation addresses must be valid class D addresses, i.e., in the range to




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.


magent (8), multicastgroups (5), RFC-988


Jay Kistler, 1990, Created


19.23 mcstgrps(5)


multicastgroups - multicastgroups file specification


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:

  <multicast address> <key-high> <key-low> <group name>

All addresses are in internet dot format (a.b.c.d), and must be valid class D addresses, i.e., in the range to Membership keys are represented as a pair of 32-bit hex numbers. Unrestricted groups should have null keys (i.e., 00000000).




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.

Only unrestricted groups should be used. The protection offered by restricted groups is bogus, and was never tested.


magent (8), multicastgroups (5), RFC-988


Jay Kistler, 1990, Created


19.24 servers(5)


servers - map server names to numbers


Each file server has a file, /vice/db/servers, 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 not be reused. You should not reassign a server a new id without initializing the server.

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.

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 not be allocated from the other subrange, and vice-versa.

The format of the file is the full server name (e.g. 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:

GRIEG.CODA.CS.CMU.EDU           204
HAYDN.CODA.CS.CMU.EDU           205




The server numbers and replicated volume prefixes are pulled from the same number space. Separation is enforced only by convention.

This file and /vice/db/hosts should be combined.


vrdb (5), vsgdb (5), maxgroupid (5), hosts (5)


Maria R. Ebling, 1990, Created


19.25 user.coda(5)


19.26 passwd.coda(5)


passwd.coda - Coda user identification file


This file specifies initial cleartext passwords for Coda users. The format of the file is:

uid<TAB>acutal cleartext password<TAB>any desired info



is a Coda user id.

Cleartext Password

is the password to use for this ViceId.

Other user info

is other information about the user you want to include, e.g. the user name

WARNING this file must be owned by root and not be readable by any other user.

This file is translated into a Coda encrypted password file by initpw(8).


initpw(8), vice.pcf(5), pwd2pdb(8)


Lesa Gresh, 1998, created \newpage

19.27 vicetab(5)


vicetab - Vice Filesystem Table


vicetab 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:

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

where column 1 specifies the server as returned by the system call gethostbyname().

Column 2 specifies the directory of the Coda data tree which must be a local file system partition for optimal performance. NOTE:if a server serves than more than one Coda data parition, each data partition must have a seperate entry in vicetab.

Column 3 specifies the Coda partition type.

Column 4 specifies the width and depth of the ftree.

In the case of the backup coordinator, only the first three columns are used, with a partition type of backup specified in the third column.

This file should only be edited on the designated SCM machine and then allowed to propagate. FILES



None we currently are aware of.


makeftree (8)


Henry M. Pierce, 1997, created


19.28 volulist(5)


volumelist - volumelist file specification


Every server keeps a list of volumes for which it is the custodian. This list is in /vice/vol/VolumeList. Every time a volume is created, an entry corresponding to that volume is made in this list. uses this list to generate the Volume Location Data Base (VLDB).

The first few lines of this file contain information pertaining to the disk partitions. These lines have the following format:

P<partition-name> H<hostname> T<total usable space on this partition> F<free space on this partition>

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:

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>




createvol (8), createvol_rep (8), volutil (8), (8)


Puneet Kumar, 1990, created


19.29 vrdb(5)


vrdb - Volume Replication Data Base specification


The volume replication data base is stored in binary form in /vice/db/VRDB on each file server. The makevrdb option of the volutil(8) program constructs the VRDB on the system control machine (SCM).

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.

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:

<group volname> <group volnum> <# of replicas> <rwvol 1> ... <rwvol 8> <VSG num>

A sample line from the VRList is:

project.coda.src 7f000010 3 c9000012 ca000013 cb000013 0 0 0 0 0 E0000107

Note that all volume and VSG numbers are given in hex. Details of the VRDB structure can be found in <vrdb.h>.





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.

The maximum number of replication sites is fixed at 8. Adding, deleting, or moving replication sites after creation is not supported.


volutil (8), maxgroupid (5), vsgdb (5)


Jay Kistler, 1990, created


19.30 vrlist(5)


vrlist - vrlist file specification


19.31 vsgdb(5)


vsgdb - Volume Storage Group Data Base specification


The volume storage group data base is stored in ASCII form in /vice/db/VSGDB 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:

<VSG number> <server-name 1> ... <server-name n>

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:

E0000107 mahler vivaldi ravel

The VSGDB is consulted by the createvol_rep (8) 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 vrdb) (5) entry for the new replicated volume.




servers (5), vrdb (5), createvol_rep (8)


Jay Kistler, 1990, Created


19.32 vstab(5)


vstab - vstab file specification


The file /usr/coda/etc/vstab contains configuration parameters for the Coda cache manager, venus (8). The parameters override default values compiled into Venus, and may themselves be overridden by command-line arguments supplied to Venus at startup.

The file should contain a single line with the following format:

<mount point>:<kernel device>:<default-host list>:<cache directory>:<cache blocks>:<1>

A sample vstab entry is:


Note that the format of the default-host list is <host1,host2,...,hostn>. There should be no space between the ``:'' separator character and the beginning or end of a field.





The last parameter is deprecated and should be removed.

This file is also read by clog (8) (and perhaps other programs) which assume that host-list specifies the hosts running auth servers.


venus (8), vutil (8)


Jay Kistler, 1990, Created


19.33 au(8)


au - add a user


au [-x] [-h host] [-p portal] <cp | cu | nu | du>


au is used to add, delete, or change user information. au 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. au supports the following options:


Turns on debugging.

-h hostname

Attatch to hostname to do the authentication. hostname should be the SCM.

-p portal

Port to bind to. The default portal is coda_auth.


Change password. Use this to change a users vice password.


Change user information. Use this to change password and other user information.


New user. The nu option tells au to add a new password entry to the vice password database.


Delete user. The du option tells au to delete the given user from the password database.


You must be a Coda system administrator to ru au.


au echos new passwords to the terminal as they are typed in.


1987, Adapted from AFS-2

Joshua Raiff, 1993, Created man page


19.34 auth2(8)


auth2 - authentication server


auth2 [-r] [-chk] [-x debuglevel] [-p pwfile] [-tk tokenkey] [-fk filekey]


auth2 is the Coda authentication server. Clients need to have an authentication token from auth2 in order to establish authenticated connections to Coda file servers.

auth2 supports the following commands line options:


Tells auth2 to print log entries to the controlling tty rather than a log file.


Causes auth2 to only validate passwords. New password entries cannot be added via this server instance. Servers started with the -chk option are slave servers. There should only be one master server in the system.

-x debuglevel

Sets the server debug level. This level controls the amount of debugging information printed by the server.

-p pwfile

Used to tell auth2 where its password file is. Typically this file is /vice/db/

-tk tokenkey

Specifies where the token key file auth2 should use when encrypting tokens.

-fk filekey

Name of file containing the key decrypt password file with.


authmon (8)


1987, Adapted from AFS-2.

Joshua Raiff, 1993, Created man page.


19.35 backup(8)


backup - Volume by volume backup of the Coda File System


backup [-p poll_period] [-t timeout] <dumplist> [dumpdir]


backup performs the clone and dump phases of the Coda backup mechanism. dumplist is a file as described in dumplist(5). It also reads vicetab which is described in vicetab(5) to know where to place dump files.

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 backuplogs(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 dumplist.

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.

backup supports the following command line options:

-p poll_period

Number of seconds to sleep between polls a servers that backup thinks are down.

-t timeout

Timout value, in seconds, for RPC2 calls.


volutil (8), dumplist (5), backuplogs (5), Backup chapter of the Coda Manual.


David C. Steere, 1991, Created updated 1998, -hmp


19.36 bldvldb(8)

NAME - build a new Volume Location Data Base (VLDB)


DESCRIPTION builds a new volume location data base VLDB. It uses the /vice/db/hosts file to get a list of servers to use to retrieve the current list of volumes. It gets the list from the /vice/vol/VolumeList file on each server. It combines the list into /vice/vol/BigVolumeList and passes the combined list as a parameter to the volutil makevldb command. This command produces a new VLDB in /vice/db and updates the files AllVolumes and partitions in /vice/vol. You must have root priveledges to run this command.


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 /vice/db/hosts. The first is ftp. In order for this to succeed, there has to be a file called ".anonr" in the directory /vice/vol, which is globally readable and contains a line with the word "VolumeList" in it. If is unable to get the file via ftp, it will attempt to use the CMU RFS remote file system. If neither mechanism works, will skip over that servers volumes when building the VLDB. 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.



is created


is created


on each server is used to build the VLDB


is a list of the active servers


is the result of combining /vice/vol/VolumeList from each server


update (8), volutil (8)


Puneet Kumar, 1990, Created


19.37 crvol(8)


createvol - create a non-replicated volume


createvol <volume-name> <server-name> <partition-name>


createvol is used to create a Coda non-replicated volume on the specified partition (<partion-name>) and server (<server-name>). The volume number is assigned by the server automatically; the name is specified by the invoker (<volume-name>).

createvol first checks in /vice/vol/AllVolumes to see if the volume-name already exists. If not, it uses the volutil create command to create the volume at the specified server. It then uses (8) to build the Volume Location Data Base (VLDB).

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 cfs(1) command.


To Create a volume for user "hbovik" on server "mahler":

createvol user.hbovik mahler /vicepa


This command does not create the mount point to the volume within the file system hierarchy. This must be created by the cfs mkmount(1) command.


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 /vice/vol/VolumeList file on the server to see if the volume name exists at that server.



used to find out if volume already exists


name of volume created is appended to it


cfs (1), (8), volutil (8)


Puneet Kumar, 1990, created


19.38 crvolrep(8)


createvol_rep - create read-write replicated volume


createvol_rep <volume-name> <vsgaddr> <partition-name> [rep group id]


createvol_rep is a front end to volutil createvol_rep and is used to create a Coda read/write replicated volume. The invoker must specify the volume name (<volume-name>), the replication sites via a Volume Server Group address (<vsgaddr>), the partition on which the volume should be created (<partition-name>), and an optional Group Id.

createvol_rep first checks in /vice/vol/AllVolumes and /vice/vol/VRList to see if the volume name already exists. If not, it uses the volutil create_rep 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).

The replication sites are determined from the <vsgaddr> and the /vice/db/VSGDB file. The Rep Group Id specifies the "replicated" volumeid of the volume being created. By default, the group id in /vice/vol/maxgroupid is used. Each time it is used it is also updated by adding 1 to it.

After the replicas are created at each replication site, a new VLDB is built automatically using, and the Volume Replication List in /vice/vol/VRList 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 "volutil makevrdb /vice/vol/VRList" command.


To create a replicated volume "coda.rep" on 3 sites foo, bar and gorp use:

createvol_rep coda.rep E0000107 /vicapa

where /vice/db/VSGDB has an entry "E0000107 foo bar gorp" in it.

To assign a predetermined Group Id, use

createvol_rep coda.rep E0000107 /vicepa 7F000003

where "7F000003" is the Group Id.


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 volutil create_rep command. The invoker must check /vice/vol/VRList and /vice/vol/VolumeList at each replication site to see if the volume was created.



contains information on replicated volumes


name of volume created at each site is appended to it


is used to describe the replicated volumes in terms of its non-replicated members.


is used to translate the VSG address to replication sites


is used to check if volume exists


is used to assign a group id to the replicated volume

SEE ALSO (8), volutil (8), createvol (8)


Puneet Kumar, 1990, Created


19.39 initpw(8)


initpw - Initialize the auth2 password database.


initpw [-k key]


initpw initializes the auth2 password database by reading entries as specified in passwd_coda(5) and writes the corresponding encrypted entries to stdout. initpw supports the following command line options:

-k key

Using the -k option allows you to specify the encryption key to use when encrypting cleartext passwords. Currently you must give "drseuss " as the key.

initpw expects to receive lines of the form:

<ViceId> <Clear Password> <Other user info>
See passwd.coda(5).


initpw -k "drseuss " < /vice/db/passwd.coda > /vice/db/


auth2 (8), passwd.coda(5)


1987, Adapted from AFS-2

Joshua Raiff, 1993, Created man page

Lesa Gresh, 1998, modified


19.40 makeftree(8)


makeftree - format a Coda Data Storage partition to use b-tree structure.


makeftree <vicetab;gt; <partition_path>


makeftree 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 FTREEDB at the head of the partition.

The depth and width must be specifed in vicetab


makeftree expects the file FTREEDB to already exist before it is run. Before running

 touch /<partition_path>/FTREEDB.
must be issued to avoid an abort.


vicetab (5)


Henry M. Pierce, 1998, Created man page


19.41 merge(8)


merge - merge incremental dumps onto full dumps for restore


merge <output file> <full dump> <incremental dump>


merge 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.

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.

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).

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.


volutil (8), restore (1)


David C. Steere, 1991, created


19.42 norton(8)


norton - Coda file server RVM debugger




Norton is a utility program that allows you to display Coda file server structures that are stored in RVM. Eventually, Norton will be a full special purpose debugger that allows you to manipulate the structures as well. Nortons command interface uses the gnu readline library which features Emacs style command editting as well as maintaining a command history. Command completion is also supported by using <tab> and <esc>-?].

The available commands are:

show directory <volid> <vnum> <unique>

Lists the contents of the directory indicated by volid.vnum.unique. Each entries vnode number and uniquifier are also listed.

delete name <volid> <vnode> <unique> <file> <flag>

remove file from the directory specified by volid.vnode.unique. If flag is nonzero the linkcount of the directory is reduced by one. NOTE: delete name does not do anything to the vnodes associated with file, you must remove the vnodes by hand or update their link count.

delete volume <volid>

mark a volume with a "destroyme" flag, so that the salvager will destroy it on the next serverstartup.

examine <addr> <len>

Print <len> bytes starting from <addr> in hex and ascii.

list volumes

Display a list of all the volumes on the server. This list includes the volume index, name, number, and type.

show free large | small

Display all of the vnodes on either the large or small free vnode list.

show heap

Display RVM heap usage.

show index <volname> | <volid>

Display the RVM index of the given volume name or number.

show vnode <volid> [ <vnode> | ? <unique>]

Show the specified vnode. If a ? is given rather than a vnode number, all of the volumes vnode lists are searched for a vnode with a matching uniquifier.

show volume <volname> | <volid>

Show a summary of the specified volume.

show volume details <volname> | <volid>

Show all of the RVM state of the specified volume.

create name < parentvolid>< parentvnode>< parentuniqifier>< name>< childvnode>< childuniqifier>

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.

x <addr> <len>

Print <len> bytes starting from <addr> in hex and ascii. An alias for examine.


Joshua Raiff, 1995, Created. Peter Braam, 1997, new features.


19.43 pcfgen(8)


19.44 prgvol(8)


purgevol - delete a non-replicated volume


purgevol <volumename>


purgevol is a front-end to the volutil purgevol command and is used to delete a non-replicated volume from the Coda system. purgevol determines the location of the volume using the readable version of the VLDB located in /vice/vol/AllVolumes. It then uses the volutil utility to purge the volume at the volumes site. Finally, it builds a new VLDB using the bldvldb(8) script.

Purgevol is similar to the volutil purge, 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.



updated by deleting the entry for the purged volume.


updated by the remote server as a side effect of purging the volume.

SEE ALSO, purgevol_rep(8), volutil(8)


David Steere, 1990, Created


19.45 prgvolre(8)


purgevol_rep - delete a replicated volume


purgevol_rep <volumename>


purgevol_rep is a front-end to the volutil purgevol_rep command and is used to delete a replicated volume from the Coda system. purgevol_rep determines the replicated volumeIds corresponding to this volume by examining the readable version of the VRDB located in /vice/vol/VRList. It then uses the volutil utility to purge the individual replicas at the sites of replication. Next, it removes the entry for the deleted volume from the /vice/vol/VRList and builds a new VRDB. Finally, it builds a new VLDB using the bldvldb(8) script. Like the other volume utilities, purgevol_rep must be run on the SCM by root.



updated by removing the entries for the replicas of the purged volume.


updated by the remote server as a side effect of purging the volume.


updated by deleting the entry for the purged volume.

SEE ALSO, purgevol(8), volutil(8)


David Steere, 1990, Created


19.46 pwd2pdb(8)


19.47 readdump(8)


readdump - Utility to examine dumpfiles created by the Coda backup facility


readdump [dumpfile]


The readdump 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.

The readdump program supports the following commands:

openDumpFile <dumpfile>



setIndex <index type>


skipVnodes <nVnodes>


readdump uses the ci command interface, which allows the use of unique prefixes for commands. Unspecified parameters will be prompted for, and default values can be used. The showHeader command prints out the header of the dump, which is seperate from the header of the volume that was dumped. The showVolumeDiskData prints out the header of the volume.

The dump contains two streams of vnodes, one for directories and one for files and symbolic links. The setIndex command specifies to readdump which stream you wish to examine. Once an index has been specified, the nextVnode command displays the next Vnode (object) in the stream. Note that movement through the stream is one-directional. To revisit a Vnode, use the setIndex command to reset the program back to the beginning of the stream. One can jump through the index by use of the skipVnodes command, which takes the number of vnodes to skip, and reads past (without displaying) that many vnodes in the stream.

Future Work

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.


merge (8), backup (8), volutil (8), Coda Manual


David C. Steere, 1991, Created


19.48 codasrv(8)


codasrv - CFS file server


codasrv [-d (debug level)] [-rpcdebug rpc2debuglevel] [-p (number of processes)] [-b (buffers)]

[-l (large vnodes)] [-s (small vnodes)] [-k (stack size)]

[-w (wait interval)] [-r (RPC retry count)]

[-o (RPC timeout)] [-c (check interval)]

[-t (RPC trace buffers)] [-forcesalvage]

[-quicksalvage] [-rvm logdevice datadevice length] [-nores]

[-trunc percent] [-nocmp] [-nopy] [-nodumpvm] [-nosalvageonshutdown]

[-mondhost hostname] [-mondportal port] [-debarrenize] [-optstore]

[-rvmopt] [-newchecklevel checklevel]


codasrv is the CFS vice file server. It services requests from client machines venus processes and maintains the file system.

Srvs command line options are:

-d <debug level>

Sets the internal debugging level to <debug level>. This controls the amount of debugging output codasrv will generate.

-p <number of processes>

Sets the number of light weight processes that will be used to handle concurrent requests.

-b buffers

Sets the number of internal buffers used by codasrv for the dir package.

-l <large vnodes>

number of large vnodes in lru cache

-s <small vnodes>

number of small vnodes in lru cache

-k <stack size>

stack size of LWP threads in Kbytes

-w <wait interval>

interval for CallBackCheckLWP to see which clients are alive

-r <RPC retry count>

number of times a call is retried before reporting death

-o <RPC timeout>

default timeout for all rpcs

-c <check interval>

The interval at which shutdown is checked

-t <RPC trace buffers>

number of entries in the rpc trace buffer


force a full salvage on all volumes


salvage only the headers of the volumes - currently it always does a full

-rvm logdevice datadevice length

The -rvm 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.


Turn off resolution on the servers

-trunc percent

Specify how full the log can get before it is truncated. Default is 50%


Directory replica contents will not be checked for equality at end of resolution


Suppress polling and yielding by threads that run for a long period


Do not dump in-memory copy of recoverable segment before shutdown


Do not salvage volumes on shutdown

-mondhost hostname

Host where mond database is stored

-mondportal port

Port to use when contacting the mond host.


Create an inode for a vnode if the inode cannot be found by the salvager


Optimized Stores - return to the client before sftp completes


Turn on inter/intra transaction rvm optimizations

-newchecklevel checklevel

Set the level of checking done by new plumber.





startserver (8)


Joshua Raiff, 1993, Created man page


19.49 startserver(8)


startserver - Start the CFS file server




startserver 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.







codasrv (8)


Joshua Raiff, 1993, Created man page


19.50 updtclnt(8)


updateclnt - update client executables


updateclnt [ -d debug_level ] [ -h host_name ] [ -q service_name ] [ -w wait_interval ] [ -r reps ]


The updateclnt command is a client process to the updatesrv 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:

-d debug_level

This option changes the debugging level. The higher the debug_level, the more information is printed. Maximum debugging level is 10.

-h host_name

This is the hostname of the control machine with which this process keeps up-to-date. Default: scm.

-q service_name

This is the name in /etc/services that should be used as the connect portal on the machine specified by host_name above. Default: rupdsrv.

-w wait_interval

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).


This option forces a .BAK file to be kept for any file that is changed.

-r reps

This is the number of wait intervals between long checks. Files are checked at two intervals. The interval specified by -w is used for those files in /vice/db. All other files are checked once each -r repetitions of length -w. Default: 6, so the long interval is 30min.

Updateclnt checks /vice/db every wait_interval seconds. This directory contains a file called files. 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 files file is defined below.


The command updateclnt -h mahler would cause the client machine to check the host "mahler" every 5 minutes to see if any of the /vice/db files have changed and every 30 minutes to see if any other files have changed. Normally the command is invoked by issuing the updatemon (8) command with the same operands.


The format of the files file is one file name per line. A "-" as the first character on the line causes the file to be deleted instead of copied.


The updateclnt program can have its debug level turned on while it is running by sending a kill -TSTP signal to a running updateclnt. To reset the debug level back to zero, send a kill -HUP signal to the running updateclnt. This also causes the UpdateLog file to not be written anymore.



is the name of the log file for the updateclnt command. It can be viewed by using the command tail -f /vice/file/UpdateLog. It is only written if debugging has been started.


is the pid of the updateclnt process.


is the pid of the updatemon process that is keeping updateclnt running.


There is no easy way to add to the list of directories checked.

The -r option is now obsolete as updateclnt does not update any directory other then /vice/db.


updatesrv (8)


Maria R. Ebling, 1990, Adapted from AFS


19.51 updtsrv(8)


updatesrv - update server files


updatesrv [ -d debug_level ] [ -l number_of_lwps ] [ -p prefix ] [ -s ] [ -q service_number ]


The updatesrv command is a read-only server that responds to requests for files by name. The operands that it accepts are:

-d debug_level

This is used to increase the level of messages written to the log file.

-l number_of_lwps

This operand is used to specify how many lwps will be used to answer file requests. Default: 2.

-p prefix

This name, prefixed to all file requests, is used to limit the files that can be requested.

-q service_name

This is the service name in /etc/services that is to be used. Default: rupdsrv.


The command updatesrv -s -p / would invoke the updatesrv process and cause the files to be served relative to / on the server machine.

The command updatesrv -s -p /vice/bin would cause the files to be served relative to /vice/bin on the server machine.


The UpdateLog file will contain useful information. Issuing a kill -TSTP signal to a running updatesrv will increase the level of debugging messages. The debugging messages can be turned off by issuing a kill -HUP signal. This will also cause the log file to no longer be written.



This log of the messages from updatesrv is kept in the directory specified by the -p operand on the invocation. This log file is only written when debugging is enabled.


This file contains the pid of the updatesrv process. It is kept in the directory specified on the -p operand on invocation of the command.


It does not yet use any password authentication to stop others from using it to fetch files from servers.


checkvenus(8) updateclnt(8)


Maria R. Ebling, 1990, Adapted from AFS-2


19.52 venus(8)


venus - client cache manager


venus [ -k kernel device ] [ -h host list ] [ -cf cache files ] [ -c cache blocks ] [-mles CML entries]

[ -d debug level ] [-rpcdebug rpc2debuglevel] [ -r root volume ] [ -f cache directory ] [ -m COP modes ]

[ -mc 0 | 1 ] [ -console console file ] [ -retries RPC2 retries ] [ -timeout RPC2 timeout ]

[ -ws SFTP window size ] [ -sa SFTP send ahead ] [ -ap SFTP ack point ] [ -init ] [ -p ]

[ -hdbes hoard entries] [-rvmt RVM type] [-sim infile outfile filtfile systype]

[ -mondhost hostname] [ -mondport port ] [ -maxprefetchers fetch threads ]

[ -maxworkers work threads] [ -maxcbservers cb threads ] [ -vld device ] [ -vlds size ]

[-vdd device ] [ -vdds size ] [ -rdscs chunk size ] [ -rdsnl nlists ] [ -logopts 0 | 1 ]

[ -swt weight ] [ -mwt weight ] [ -ssf scale factor ] [ mount point ]


venus 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 venus (see <venus.private.h>) for these values. Some of these are overridden by the values in the vstab(5), provided that it exists. Both default and vstab values may be overridden with command-line arguments. Venus must be run as root.

The command-line options are:

-k kernel device

Take kernel device to be the device for kernel/venus communication.

Default: /dev/cfs0

-h host list

Take comma-separated host list to be the initial set of hosts to be used for volume-location requests.

-cf cache files

Limit the size of the file cache to cache files entries.

Default: 512

-c cache blocks

Limit the size of the file cache to cache blocks 1K blocks.

Default: 8192

-mles CML entries

Number of Cache Modify Log entries

-vols volumes

Limit the size of the volume cache to volumes entries.

Default: 128

-vsgs vsgs

Limit the size of the VSG cache to vsgs entries.

Default: 64

-d debug level

Initialize the debug level to debug level. Meaningful values are {0, 1, 10, 100, 1000}.

Default: 0

-r root volume

Take root volume 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.]

Default: none

-f cache directory

Take cache directory 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 rwx------ to protect the cache from malicious local users.

Default: /usr/coda/venus.cache

-m COP modes

Controls what Coda Optimistic Protocol (COP) options are enabled. COP modes is interpreted according to the following bit-mask: [ PIGGYCOP2 | ASYNCCOP2 | ASYNCCOP1 ]. Only some combinations are legal.

Default: [ PIGGYCOP2 | ASYNCCOP2 ]

-mc 0 | 1

Controls whether multicast is used or not (0

-console console file

Redirects console messages to console file.

Default: /dev/console

-retries RPC2 retries

Sets the number of RPC2 retries to RPC2 retries.

Default: 4

-timeout RPC2 timeout

Sets the RPC2 timeout period to RPC2 timeout seconds.

Default: 30

-ws SFTP window size

Sets the SFTP window size to SFTP window size packets.

Default: 8

-sa SFTP send ahead

Sets the SFTP send ahead to SFTP send ahead packets.

Default: 4

-ap SFTP ack point

Sets the SFTP ack point to SFTP ack point packets.

Default: 4


Initializes LEFTPAREN i.e., clears) file, volume, and VSG caches.


Enables profiling.

-hdbes hoard entries

Number of hoard database entries.

-rvmt RVMT type

Media that RVM resides on. Meaningful values are: 1

-sim infile outfile filtfile systype

Turn on simulator mode. infile is a trace to load in to the simulation. outfile is the output file for the simulation. filtfile is a filter for the trace. And systype is the system type the trace was taken on.

-mondhost hostname

Host where mond database is stored

-mondportal port

Port to use when contacting the mond host.

-maxprefetchers fetch threads

Maximum number of threads doing prefetch ioctls

-maxworkers work threads

Number of worker threads.

-maxcbservers cb threads

Number of callback server threads.

-vld device

Location of the venus log device.

Default: /usr/coda/LOG

-vlds size

Size of the log device.

-vdd device

Location of the venus data device.

Default: /usr/coda/DATA

-rdscs chunk size

Specify RDS chunk size.

-rdsnl nlists

Number of RDS nlists.

-logopts 0 | 1

Turn on log optimization.

-swt weight

Short term cache priority weight.

-mwt weight

Medium term cache priority weight.

-ssf scale factor

Short term cache scale factor.

mount point

Directory to serve as the mount point for Coda.

Default: /coda


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>.

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.

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).



<cache directory>/venus.log

<cache directory>/pid



A mount point of /coda is assumed by the pioctl library.

A cache directory of /usr/coda/venus.cache is assumed by vutil (8v).


vstab (5), cfsunmount (8v), vutil (8v)


Jay Kistler, 1990, Created

Joshua Raiff, 1993, Documented added switches


19.53 volutil(8)


volutil - volume utility subsystem


volutil [-h <server>] [ -t timeout] [ -d debuglevel] <command> <parameters ... >


Volutil 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 <command> 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.

ancient <group-ID> <rep-ID>

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.

backup <volume-ID>

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.

clone volume-ID [-n new-volume-name]

Create a read only clone of a read write volume with (replica) ID (<volume-ID>). 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 <new-volume-name> parameter. Default value is volume-name.readonly. The clone(8) command can be used to call volutil clone.

create <partition-path> <volume-name>

Create a nonreplicated read-write volume named <volume-name> on partition named <partition-path>. The createvol(8) command is a simplified front-end for this option.

create_rep <partition-path> <volume-name> <group-ID>

Create a replicated read-write volume named <volume-name> on partition named <partition-path>. The <group-ID> parameter is used to specify the ID of the replicated volume to which this replica will belong. The createvol_rep(8) command will also create a replicated volume.

dump [-i] <volume-ID> <file-name>

Dump the entire contents of a volume (volume-ID in Hex) to a file (file-name). 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.

dumpmem <file-name> <address> <size>

Dump <size> bytes starting at <address> into <file-name>.

elapse <on | off> <resolution | cb | mond | volDump> [MultiRPC]

Turn on or off timers for the given subsystem.

info [-all] <volume-name | volume-number> <file-name>

Print in ascii the contents of a volume into a file (<file-name>). 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.

lock <volume-ID>

Lock a volume to prevent write access to the volume. To other users it will appear as if the operation would time out.

lookup <volume-name | volume-ID> <file-name>

Print information about a volume (specified by volume-name or volume-ID specified in Hex) in file-name. Only meta-information, such as replicated group-ID, location, etc. is printed.

makevldb <VolumeList>

Create a new Volume Location Database VLDB. VolumeList names a file containing volume parameters for all volumes in the system. This command typically is run on the system control machine. See also bldvldb(8) and volumelist(5).

makevrdb <vrlist>

Create a new Volume Replication Data Base (VRDB). <vrlist> 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.

purge <volume-ID> <volume-name>

Delete a volume. For replicated volumes purge must be called from each server individually on the replicas at the different servers. (See purgevol-rep(8))

restore <file-name> <partition-path> [<volume-ID> <volume-name>]

Create a new volume on the partition named by <partition-path> and read in the contents from a dump in file <file-name>. 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.

rvmsize <volume-ID>

Print the RVM statistics for the volume <volume-ID>.

setdebug <level>

Set the debug level for the volume and directory packages to level. To reset it use zero for the level argument. The rpc2 debug level is set to level/10.

setlogparms <volume-ID> [<reson> <1 | 0>] [<logsize> <size>]

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 reson and can be turned off by specifying 0. The size of the log can also be changed for the volume. The size parameter refers to the number of maximum entries in the log. This should be a multiple of 32. Typically this is set to 8192.

setvv <volumeNumber> <vnodeNumber> <Uniquifier> <version numbers (8)> <host unique flags>

Set the version vector for a vnode (with fid = <volumeNumber>.<vnodeNumber>.<Uniquifier>). The new version vector is specified by the <version numbers> and the <host unique flags> triple.

showvnode <volumeNumber> <vnodeNumber> <Uniquifier> <file-name>

Print the contents of a vnode (with fid = <volumeNumber>.<vnodeNumber>.<Uniquifier>). into <file-name>.


Bring all volumes offline and bring down the server.


Save the fileserver log output (in SrvLog.old) and start a new SrvLog.

timing on | off <filename>

Turn timing on or off.


Forcibly truncate the RVM log.

unlock <volume-ID>

Unlock a volume locked via the volutil lock command. (volume-ID) should be in Hex


Make the file server read in a new VLDB and VRDB. The server assumes the databases to exist in /vice/db/VLDB and /vice/db/VRDB. This utility is useful for reading in new databases at non-scm machines.


This command must be run as root. It works only on the machine running the server. Also, the token file /vice/db/ must be accessible.


The salvage option to volutil doesn't work right. Please don't try it.








vrdb(5), volumelist(5), bldvldb(8), createvol(8), createvol_rep(8), purgevol(8), purgevol_rep(8)


Puneet Kumar, David Steere, 1990, Created


19.54 vutil(8)


vutil - venus utility program


vutil [-cop COP modes] [ -cs ] [-d debug level] [-mc 0 | 1 ] [-p 0 | 1]

[-shutdown] [-stats] [-swap]


vutil 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.

The parameters are:

-cop COP modes

Controls what Coda Optimistic Protocol (COP) options are enabled. COP modes is interpreted according to the following bit-mask: [PIGGYCOP2 | ASYNCCOP2 | ASYNCCOP1 ]. Only some combinations are legal.


Clears internal counters used in statistics reporting.

-d debug level

Sets the debug level to debug level. Meaningful values are {0, 1, 10, 100, 1000}.

-mc 0 | 1

Enable/disables multicast (0 = ``OFF,'' 1 = ``ON'')

-p 0 | 1

Enables/disables profiling (0 = ``OFF,'' 1 = ``ON'')


Shuts Venus down gracefully.


Causes Venus to dump internal counters and other statistics to its log file.


Causes Venus to move its current log file to <log-file>.old and reinitialize <log-file>.


Only the super user can run vutil.





Venus cache directory is assumed to be /usr/coda/venus.cache.


venus LEFTPAREN 8)


Jay Kistler, 1990, Created

Next Previous Contents