Coda File System

Next Previous Contents

19. Unix Manual Pages

\newpage

19.1 cfs(1)

NAME

cfs - Coda File System Interface Program

SYNOPSIS

cfs [adaptive|strong]

cfs strong

cfs checkpointml

cfs checkservers

cfs checkvolumes

cfs clearpriorities

cfs [@cpu|@sys]

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 replayclosure

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

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

cfs truncatelog

cfs waitforever [-on] [-off]

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

cfs disconnect

cfs reconnect

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

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

DESCRIPTION

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

[adaptive|strong]

Use `strong' to override adaptation to changing network conditions. Revert to automatic adaptation using `adaptive'. This command is useful to force strong connectivity semantics even over slow or unreliable links.

checkpointml

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 .

checkservers

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

checkvolumes

Check volume/name mappings.

clearpriorities

Clear short-term priorities used for cache management.

[@cpu|@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.

endrepair

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

Abbreviation: er .

examineclosure

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

Abbreviation: ec

flushcache

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.

flushobject

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

Abbreviation: fl

flushvolume

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.

getfid

Map the given paths to Coda file ids.

Abbreviation: gf

getpath

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

Abbreviation: gp

listacl

List access control list for each of the given directories.

Abbreviation: la

listcache

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

Abbreviation: lc

listvol

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

Abbreviation: lv

lsmount

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

mkmount

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

purgeml

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

replayclosure

Replay reintegration closure.

Abbreviation: rc

rmmount

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

Abbreviation: rmm

setacl

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

truncatelog

Truncate the RVM log at this instant.

Abbreviation: tl

waitforever

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

whereis

List the servers that the given files reside on.

disconnect

Partition your client from the Coda file servers.

reconnect

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

writedisconnect

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

writereconnect

Strongly connect to the servers.

Abbreviation: wr

SEE ALSO

chmod (1)

AUTHOR

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

\newpage

19.2 clog(1)

NAME

clog - Authenticate yourself to the Coda file system

SYNOPSIS

clog [-pipe] [-test] [-host < authserver > ] [-kerberos4|-kerberos5|-coda] [-tofile < file > ] [-fromfile < file > ] [ < username > ]

DESCRIPTION

This command enables users to get tokens to use for authenticated communication with a Coda File System. The given name and a password or kerberos token 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:

-pipe

For use in shell scripts, the password is read from stdin. This option is also enabled when stdin is not a tty.

-test

Test the clog-venus token passing code.

-host < authserver >

Specify the host where the authentication server is running.

-kerberos4|-kerberos5|-coda

Authentication mechanism, use kerberos tickets or coda password to identify yourself to the authentication server.

-tofile < file >

After obtaining a token from the authentication server, write it to a file.

-fromfile < file >

Read a previously saved token from a file and present it to venus.

< username >

Login name you wish to be identified as.

BUGS

The on-disk tokens are not encrypted. The -pipe option should be dropped, the isatty(stdin) test is sufficient for most cases. The -test option should also test the reading and writing code of token files.

SEE ALSO

cunlog (1), venus (8)

AUTHOR

1987, Adapted from AFS-2

Maria R. Ebling, 1990, Created man page

\newpage

19.3 cmon(1)

NAME

cmon - Coda server monitor

SYNOPSIS

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

DESCRIPTION

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:

-a

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:

mon

time at which this cmon process was created.

prob

time at which the server was last probed.

succ

time at which the server last responded to a probe.

up

time at which the server process was started.

bind

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:

sys

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

user

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

util

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

The RPC data is as follows:

conn

number of RPC connections.

wkst

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

call

relative or absolute number of RPC calls received.

pki

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

pko

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

byi

bytes corresponding to pki.

byo

bytes corresponding to pko.

The DSK data is as follows:

max1

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.

max2

identity and percent usage of second most full disk.

max3

identity and percent usage of third most full disk.

DIAGNOSTICS

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.

BUGS

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

SEE ALSO

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

AUTHOR

M. Satyanarayanan, 1990, Created

\newpage

19.4 cpasswd(1)

NAME

cpasswd - change Coda login password

SYNOPSIS

cpasswd [-h host] [username]

DESCRIPTION

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.

FILES

/vice/db/user.coda

BUGS

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

SEE ALSO

clog (1), crypt (3)

AUTHOR

1987, Adapted from AFS-2

Maria R. Ebling, 1990, Created man page

\newpage

19.5 ctokens(1)

NAME

ctokens - list all tokens

SYNOPSIS

ctokens

DESCRIPTION

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.

BUGS

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

SEE ALSO

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

AUTHOR

1987, Adapted from AFS-2s unlog

David C. Steere, 1990, Created man page

\newpage

19.6 cunlog(1)

NAME

cunlog - Tell the Coda Venus to release authentication tokens

SYSNOPSIS

cunlog

DESCRIPTION

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 .

SEE ALSO

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

AUTHOR

1987, Adapted from AFS-2s unlog

David Steere, 1990, Created man page

\newpage

19.7 filcon(1)

NAME

filcon - the RPC2 filter control utility.

SYNOPSIS

filcon

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

DESCRIPTION

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 in coming (receive) packets or out going (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.

INTERACTIVE USAGE

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 .

listclients

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

quit

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

COMMANDLINE INVOCATIONS

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.

partition

blocks traffice between the hosts given.

heal

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

slow

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

ARGUMENTS

port

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

speed

Speed in bits per second

BUGS

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.

AUTHOR

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.

\newpage

19.8 hoard(1)

NAME

hoard - hoard database front-end

SYNOPSIS

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

DESCRIPTION

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:

1-1000

assign this object the hoard priority indicated

c

current children of this directory will inherit its hoard status

c+

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

d

current descendents of this directory will inherit its hoard status

d+

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:

clear
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 hoard program is executed by the user who is identified as the primary user in the venus.conf configuration file. If no primary user is specified, special permission is given to the console user who is logged in on the local (or first virtual) console. 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:

-d

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.

DIAGNOSTICS

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 .

BUGS

Negative priorities should be allowed.

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

SEE ALSO

venus (8)

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.9 mvdb(1)

NAME

mvdb - Atomically update files in a directory

SYNOPSIS

mvdb [-l lockfile] file1 file2 ...

or

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

DESCRIPTION

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:

-v

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

-u

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

EXAMPLE


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

BUGS

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.

AUTHOR

Created: M.Satyanarayanan, 1985

\newpage

19.10 repair(1)

NAME

repair - repair conflicts in the Coda file system

SYNOPSIS

repair [-d]

repair [-allowclear]

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

DESCRIPTION

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.

quit

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.

help

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:

checklocal

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 .

discardlocal

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.

preservelocal

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.

discardalllocal

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.

preservealllocal

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.

listlocal

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

setglobalview

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 .

setlocalview

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 .

setmixedview

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.

EXAMPLES

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

SEE ALSO

ci (3)

AUTHOR

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.

\newpage

19.11 spy(1)

NAME

spy - Report all CFS files that are opened

SYNOPSIS

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

DESCRIPTION

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.

SEE ALSO

hoard (1)

AUTHOR

Joshua Raiff, 1993, Created man page

\newpage

19.12 venussetup(1)

NAME

venus-setup setup venus on a client

SYNOPSIS

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

DESCRIPTION

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:

EXAMPLE


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.

BUGS

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.

FILES

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

SEE ALSO

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

Coda Manual: ``Installing A Coda Client''

AUTHOR

Henry M. Pierce, 1998, created

\newpage

19.13 vicesetup(1)

NAME

Vice-setup setup a Coda server

SYNOPSIS

Vice-setup

DESCRIPTION

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 :

OVERVIEW

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:

  • Creates the directories, /vice,/vice/{backup,db,srv,vol} and, /vice/vol/remote if they do not already exist.
  • Creates and sets up the authentication files needed for interserver and interclient communication.
  • Creates and sets up, /vice/db/files , which are a set of common Coda files distributed from the SCM via, updateclnt , and updatesrv .
  • Adds Coda port numbers to, /etc/services if not already present.
  • Sets up the Coda server to start at system startup if so indicated.
  • Records the hostname in, /vice/hostname .
Vice-setup-scm

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

  • Prompts for a Coda server ID in the range of 0-255, and creates the file, /vice/db/servers , with this information.
  • Creates, /vice/db/scm , with the hostname of the SCM machine being setup.
  • Creates, /vice/db/VSGDB , with the root volume number ``E0000100''.
  • Prompts for the name of the root volume and stores this information in, /vice/db/ROOTVOLUME .
Vice-setup-user

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

  • This sets up the System:Administrator group and Coda user ``admin'' then initializes, /vice/db/vice.pdb .
  • Creates, /vice/db/passwd.coda , needed to setup the initial password system.
  • Creates, /vice/db/auth.pw .
Vice-setup-rvm
  • Prompts for the RVM_LOG device.
  • Prompts for the size of the RVM_LOG device.
  • Prompts for the RVM_DATA device.
  • Prompts for the RVM_DATA size based on default values. These values must be typed exactly right to be accepted. For example, 22M must be typed exactly as, "22M".
  • Initializes the RVM_LOG and RVM_DATA devices based on the values given for RVM initialization.
  • Creates, /vice/srv.conf, with the values given for RVM.
Vice-setup-srvdir

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

  • Prompts for the location a data storage area (default is, /vicepa).
  • Creates the empty file, /vicepa/FTREEDB , which must exist in order for, makeftree , to function.
  • Creates, /vice/db/vicetab .
  • Initializes the data storage area with, makeftree .

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

BUGS

Many of the highlights are:

FILES

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

/vice/db/services

/vice/db/ROOTVOLUME

/vice/db/VSGDB

/vice/db/vice.pfc

/vice/db/vice.pdb

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

SEE ALSO

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

AUTHOR

Henry M. Pierce, 1998, created

\newpage

19.14 volmunge(1)

NAME volmunge - manipulates objects within Coda.

SYNOPSIS volmunge < -adfmov > dir
-a

Prints out everything but does not cross volume boundaries.

-d

Prints out UNIX directories, but not volume mount points.

-f

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.

-m

Prints out those objects which are volume mount points.

-o

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

-v

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

DESCRIPTION

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.

SEE ALSO

find (1), perl (1)

AUTHOR

Henry M. Pierce, 1998, created

\newpage

19.15 histo(3)

NAME

histo - histogram package

SYNOPSIS

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

DESCRIPTION

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.

DIAGNOSTICS

Negative return values indicate errors.

EXAMPLE


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


}

AUTHOR

M.Satya, 1991

\newpage

19.16 timing(3)

NAME

timing_paths - timing package

SYNOPSIS

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

DESCRIPTION

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.

DIAGNOSTICS

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.

EXAMPLE


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

AUTHOR

Gowthami Rajendran, 1991

\newpage

19.17 backuplogs(5)

NAME

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

DESCRIPTION

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.

EXAMPLE


date: Mon 01/05/98

00:05:26 Partition /backup1: 2561728 available size (1K blocks, minfree=5%), 256
1715 free blocks.
00:05:26 Partition /backup2: 2561728 available size (1K blocks, minfree=5%), 256
1715 free blocks.
00:05:26 Partition /backup3: 2559782 available size (1K blocks, minfree=5%), 255
9767 free blocks.
00:05:26 VLDBLookup: VLDB_size unset. Calling VCheckVLDB()
00:05:26 7f0003f4: cloning
00:05:29        e20000af-
>
e20000b0
00:05:33        e10000bd-
>
e10000be
00:05:36        e30000ae-
>
e30000af
00:09:34 7f0003ef: cloning
00:09:57        e2000093-
>
e20000ad
00:10:27        e10000a1-
>
e10000bb
00:10:57        e3000092-
>
e30000b4
00:29:02 Dumping 7f0003f4.e20000af to /backup1/05Jan1998/massenet.coda.cs.cmu.ed
u-7f0003f4.e20000af ...
00:29:02                Transferred 112131 bytes

00:29:02 Dumping 7f0003f4.e10000bd to /backup2/05Jan1998/poulenc.coda.cs.cmu.edu
-7f0003f4.e10000bd ...
00:29:03                Transferred 112131 bytes

00:29:03 Dumping 7f0003f4.e30000ae to /backup1/05Jan1998/rameau.coda.cs.cmu.edu-7f0003f4.e30000ae ...
00:29:14                Transferred 3768325 bytes
01:12:12 Dumping 7f0003ef.e2000093 to /backup1/05Jan1998/massenet.coda.cs.cmu.edu-7f0003ef.e2000093 ...
01:18:31                Transferred 119182513 bytes

01:18:31 Dumping 7f0003ef.e10000a1 to /backup2/05Jan1998/poulenc.coda.cs.cmu.edu-7f0003ef.e10000a1 ...
01:33:44                Transferred 119182513 bytes

01:33:44 Dumping 7f0003ef.e3000092 to /backup3/05Jan1998/rameau.coda.cs.cmu.edu-7f0003ef.e3000092 ...
01:42:03                Transferred 119172268 bytes

03:58:16                Transferred 309842 bytes

03:58:19
03:58:19 Attempting to retry any failed operations.
03:58:19
03:58:19 Successfully backed-up Volumes:
03:58:19 0x7f0003f4 (incremental)       f:u.satya2
03:58:19 0x7f0003ef                     f:u.mre
03:58:19 Only partially successfully backed-up Volumes:
03:58:19
03:58:19 Volumes that FAILED backup:
03:58:19
03:58:19 Volumes that were NOT backed-up:
03:58:19 0x7f000394                     t.test

[STATISTICAL SUMMERIES OF THE DUMP NORMALLY APPEAR HERE]

---------
>
Partition /backup:
---------
>
command: mt -f /dev/nst0 rewind
---------
>
command: restore -b 500 -s 1 -f /dev/nst0 -t /
Level 0 dump of /backup on dvorak.coda.cs.cmu.edu:/dev/sda1
Label: none
Dump   date: Mon Jan  5 04:05:14 1998
Dumped from: the epoch
         2      .
        11      ./lost+found
      2041      ./05Jan1998
      4081      ./05Jan1998/massenet.coda.cs.cmu.edu
      4082      ./05Jan1998/massenet.coda.cs.cmu.edu/7f0003f4.e20000af
      4087      ./05Jan1998/massenet.coda.cs.cmu.edu/7f0003ef.e2000093
      6121      ./05Jan1998/poulenc.coda.cs.cmu.edu
      6122      ./05Jan1998/poulenc.coda.cs.cmu.edu/7f0003f4.e10000bd
      6127      ./05Jan1998/poulenc.coda.cs.cmu.edu/7f0003ef.e10000a1
      8161      ./05Jan1998/rameau.coda.cs.cmu.edu
      8162      ./05Jan1998/rameau.coda.cs.cmu.edu/7f0003f4.e30000ae
      8167      ./05Jan1998/rameau.coda.cs.cmu.edu/7f0003ef.e3000092

SEE ALSO

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

AUTHOR

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

Henry M. Pierce, 1998, updated.

\newpage

19.18 dumpfile(5)

NAME

dump file - Format of a dump file

DESCRIPTION

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.

SEE ALSO

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

AUTHOR

Joshua Raiff, 1993, Taken from system adminstrators guide.

\newpage

19.19 dumplist(5)

NAME

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

DESCRIPTION

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.

EXAMPLE

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

NOTES

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.

SEE ALSO

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

AUTHOR

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

\newpage

19.20 groups.coda(5)

\newpage

19.21 maxgrpid(5)

NAME

maxgroupid - replicated volume number allocation mechanism

DESCRIPTION

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.

FILES

/vice/vol/maxgroupid on the SCM

BUGS

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.

SEE ALSO

servers (5), createvol_rep (8)

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.22 mcstagen(5)

NAME

multicastagents - multicastagents file specification

DESCRIPTION

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 224.0.0.0 to 239.255.255.255.

FILES

/etc/multicastagents

BUGS

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.

SEE ALSO

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

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.23 mcstgrps(5)

NAME

multicastgroups - multicastgroups file specification

DESCRIPTION

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 224.0.0.0 to 239.255.255.255. Membership keys are represented as a pair of 32-bit hex numbers. Unrestricted groups should have null keys (i.e., 00000000).

FILES

/etc/multicastgroups

BUGS

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.

SEE ALSO

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

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.24 servers(5)

NAME

servers - map server names to numbers

DESCRIPTION

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. mahler.coda.cs.cmu.edu) followed by a tab and then the servers number. Any line beginning with a "\#" is considered a comment and is ignored. The following is an example servers file:


MAHLER.CODA.CS.CMU.EDU          201
GRIEG.CODA.CS.CMU.EDU           204
HAYDN.CODA.CS.CMU.EDU           205
WAGNER.CODA.CS.CMU.EDU          206
DEBUSSY.CODA.CS.CMU.EDU         212
SCARLATTI.CODA.CS.CMU.EDU       214
ROSSINI.CODA.CS.CMU.EDU         215
PUCCINI.CODA.CS.CMU.EDU         216
GERSHWIN.CODA.CS.CMU.EDU        218
SCHUMANN.CODA.CS.CMU.EDU        219

FILES

/vice/db/servers

BUGS

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.

SEE ALSO

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

AUTHOR

Maria R. Ebling, 1990, Created

\newpage

19.25 user.coda(5)

\newpage

19.26 passwd.coda(5)

NAME

passwd.coda - Coda user identification file

DESCRIPTION

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


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

Where:

ViceId

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

SEE ALSO

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

AUTHOR

Lesa Gresh, 1998, created \newpage

19.27 vicetab(5)

NAME

vicetab - Vice Filesystem Table

DESCRIPTION

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

/vice/bin/makeftree

BUGS

None we currently are aware of.

SEE ALSO

makeftree (8)

AUTHOR

Henry M. Pierce, 1997, created

\newpage

19.28 volulist(5)

NAME

volumelist - volumelist file specification

DESCRIPTION

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. bldvldb.sh (8) 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 >

FILES

/vice/vol/VolumeList

SEE ALSO

createvol (8), createvol_rep (8), volutil (8), bldvldb.sh (8)

AUTHOR

Puneet Kumar, 1990, created

\newpage

19.29 vrdb(5)

NAME

vrdb - Volume Replication Data Base specification

DESCRIPTION

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

FILES

/vice/db/VRDB

/vice/vol/VRList

BUGS

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.

SEE ALSO

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

AUTHOR

Jay Kistler, 1990, created

\newpage

19.30 vrlist(5)

NAME

vrlist - vrlist file specification

\newpage

19.31 vsgdb(5)

NAME

vsgdb - Volume Storage Group Data Base specification

DESCRIPTION

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.

FILES

/vice/db/VSGDB

SEE ALSO

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

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.32 vstab(5)

NAME

vstab - vstab file specification

DESCRIPTION

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:

/coda:/dev/cfs0:rossini,scarlatti,puccini:/usr/coda/venus.cache:10000:1

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

FILES

/usr/coda/etc/vstab

< vstab.h >

BUGS

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.

SEE ALSO

venus (8), vutil (8)

AUTHOR

Jay Kistler, 1990, Created

\newpage

19.33 au(8)

NAME

au - add a user

SYNONPSIS

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

DESCRIPTION

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:

-x

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.

cp

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

cu

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

nu

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

du

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

DIAGNOSTICS

You must be a Coda system administrator to ru au .

BUGS

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

AUTHOR

1987, Adapted from AFS-2

Joshua Raiff, 1993, Created man page

\newpage

19.34 auth2(8)

NAME

auth2 - authentication server

SYNOPSIS

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

DESCRIPTION

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:

-r

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

-chk

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/auth2.pw.

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

SEE ALSO

authmon (8)

AUTHOR

1987, Adapted from AFS-2.

Joshua Raiff, 1993, Created man page.

\newpage

19.35 backup(8)

NAME

backup - Volume by volume backup of the Coda File System

SYNOPSIS

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

DESCRIPTION

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.

SEE ALSO

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

AUTHOR

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

\newpage

19.36 bldvldb(8)

NAME

bldvldb.sh - build a new Volume Location Data Base (VLDB)

SYNOPSIS

bldvldb.sh

DESCRIPTION

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

DIAGNOSTICS

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 bldvldb.sh is unable to get the file via ftp, it will attempt to use the CMU RFS remote file system. If neither mechanism works, bldvldb.sh 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.

FILES

/vice/vol/AllVolumes

is created

/vice/db/VLDB

is created

/vice/vol/VolumeList

on each server is used to build the VLDB

/vice/db/hosts

is a list of the active servers

/vice/vol/BigVolumeList

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

SEE ALSO

update (8), volutil (8)

AUTHOR

Puneet Kumar, 1990, Created

\newpage

19.37 crvol(8)

NAME

createvol - create a non-replicated volume

SYNOPSIS

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

DESCRIPTION

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 bldvldb.sh (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.

EXAMPLE

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


createvol user.hbovik mahler /vicepa

NOTES

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.

DIAGNOSTICS

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.

FILES

/vice/vol/AllVolumes

used to find out if volume already exists

/vice/vol/VolumeList

name of volume created is appended to it

SEE ALSO

cfs (1), bldvldb.sh (8), volutil (8)

AUTHOR

Puneet Kumar, 1990, created

\newpage

19.38 crvolrep(8)

NAME

createvol_rep - create read-write replicated volume

SYNOPSIS

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

DESCRIPTION

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 bldvldb.sh (8), 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.

EXAMPLES

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.

DIAGNOSTICS

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.

FILES

/vice/vol/VRList

contains information on replicated volumes

/vice/vol/VolumeList

name of volume created at each site is appended to it

/vice/db/VRDB

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

/vice/db/VSGDB

is used to translate the VSG address to replication sites

/vice/vol/AllVolumes

is used to check if volume exists

/vice/vol/maxgroupid

is used to assign a group id to the replicated volume

SEE ALSO

bldvldb.sh (8), volutil (8), createvol (8)

AUTHOR

Puneet Kumar, 1990, Created

\newpage

19.39 initpw(8)

NAME

initpw - Initialize the auth2 password database.

SYNOPSIS

initpw [-k key]

DESCRIPTION

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

EXAMPLE

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

SEE ALSO

auth2 (8), passwd.coda(5)

AUTHOR

1987, Adapted from AFS-2

Joshua Raiff, 1993, Created man page

Lesa Gresh, 1998, modified

\newpage

19.40 makeftree(8)

NAME

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

SYNOPSIS

makeftree < vicetab;gt; < partition_path >

DESCRIPTION

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

BUGS

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.

SEE ALSO

vicetab (5)

AUTHOR

Henry M. Pierce, 1998, Created man page

\newpage

19.41 merge(8)

NAME

merge - merge incremental dumps onto full dumps for restore

SYNOPSIS

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

DESCRIPTION

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.

SEE ALSO

volutil (8), restore (1)

AUTHOR

David C. Steere, 1991, created

\newpage

19.42 norton(8)

NAME

norton - Coda file server RVM debugger

SYNOPSIS

Norton

DESCRIPTION

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

AUTHOR

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

\newpage

19.43 pcfgen(8)

\newpage

19.44 prgvol(8)

NAME

purgevol - delete a non-replicated volume

SYNOPSIS

purgevol < volumename >

DESCRIPTION

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.

FILES

/vice/vol/AllVolumes

updated by deleting the entry for the purged volume.

/vice/vol/VolumeList

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

SEE ALSO

bldvldb.sh(8), purgevol_rep(8), volutil(8)

AUTHOR

David Steere, 1990, Created

\newpage

19.45 prgvolre(8)

NAME

purgevol_rep - delete a replicated volume

SYNOPSIS

purgevol_rep < volumename >

DESCRIPTION

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.

FILES

/vice/vol/AllVolumes

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

/vice/vol/VolumeList

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

/vice/vol/VRList

updated by deleting the entry for the purged volume.

SEE ALSO

bldvldb.sh(8), purgevol(8), volutil(8)

AUTHOR

David Steere, 1990, Created

\newpage

19.46 pwd2pdb(8)

\newpage

19.47 readdump(8)

NAME

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

SYNOPSIS

readdump [dumpfile]

DESCRIPTION

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 >
showHeader
showVolumeDiskData
setIndex < index type >
nextVnode
skipVnodes < nVnodes >
quit

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.

SEE ALSO

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

AUTHOR

David C. Steere, 1991, Created

\newpage

19.48 codasrv(8)

NAME

codasrv - CFS file server

SYNOPSIS

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]

DESCRIPTION

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

Srv s 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

-forcesalvage

force a full salvage on all volumes

-quicksalvage

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.

-nores

Turn off resolution on the servers

-trunc percent

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

-nocmp

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

-nopy

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

-nodumpvm

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

-nosalvageonshutdown

Do not salvage volumes on shutdown

-mondhost hostname

Host where mond database is stored

-mondportal port

Port to use when contacting the mond host.

-debarrenize

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

-opstore

Optimized Stores - return to the client before sftp completes

-rvmopt

Turn on inter/intra transaction rvm optimizations

-newchecklevel checklevel

Set the level of checking done by new plumber.

FILES

/vice/srv/SrvErr

/vice/srv/SrvLog*

SEE ALSO

startserver (8)

AUTHOR

Joshua Raiff, 1993, Created man page

\newpage

19.49 startserver(8)

NAME

startserver - Start the CFS file server

SYNOPSIS

startserver

DESCRIPTION

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.

FILES

codasrv

/vice/srv/SrvErr

/vice/srv/SrvLog*

/vice/srv/srv.conf

SEE ALSO

codasrv (8)

AUTHOR

Joshua Raiff, 1993, Created man page

\newpage

19.50 updtclnt(8)

NAME

updateclnt - update client executables

SYNOPSIS

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

DESCRIPTION

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

-b

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.

EXAMPLES

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.

FORMAT

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.

DIAGNOSTICS

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.

FILES

/vice/srv/UpdateLog

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.

/vice/srv/UpdatePid

is the pid of the updateclnt process.

/vice/srv/UpdateMon

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

BUGS

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 .

SEE ALSO

updatesrv (8)

AUTHOR

Maria R. Ebling, 1990, Adapted from AFS

\newpage

19.51 updtsrv(8)

NAME

updatesrv - update server files

SYNOPSIS

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

DESCRIPTION

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.

EXAMPLES

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.

DIAGNOSTICS

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.

FILES

UpdateLog

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.

pid

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.

BUGS

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

SEE ALSO

checkvenus(8) updateclnt(8)

AUTHOR

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

\newpage

19.52 venus(8)

NAME

venus - client cache manager

SYNOPSIS

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 ]

DESCRIPTION

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

-init

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

-p

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

DIAGNOSTICS

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

FILES

/usr/coda/etc/vstab

< cache directory > /venus.log

< cache directory > /pid

< venus.private.h >

BUGS

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

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

SEE ALSO

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

AUTHOR

Jay Kistler, 1990, Created

Joshua Raiff, 1993, Documented added switches

\newpage

19.53 volutil(8)

NAME

volutil - volume utility subsystem

SYNOPSIS

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

DESCRIPTION

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

NOTE: You should in all normal cases keep the resolution turned on , and the argument for reson is in that case 4 !

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

shutdown

Bring all volumes offline and bring down the server.

swaplog

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

timing on | off < filename >

Turn timing on or off.

truncatervmlog

Forcibly truncate the RVM log.

unlock < volume-ID >

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

updatedb

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.

DIAGNOSTICS

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

BUGS

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

FILES

/vice/db/VSGDB

/vice/file/SrvLog

/vice/db/VLDB

/vice/db/VRDB

/vice/vol/VRList

SEE ALSO

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

AUTHOR

Puneet Kumar, David Steere, 1990, Created

\newpage

19.54 vutil(8)

NAME

vutil - venus utility program

SYNOPSIS

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

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

DESCRIPTION

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.

-cs

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

-shutdown

Shuts Venus down gracefully.

-stats

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

-swap

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

DIAGNOSTICS

Only the super user can run vutil .

FILES

/usr/coda/venus.cache/pid

/usr/coda/venus.cahe/venus.log

BUGS

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

SEE ALSO

venus LEFTPAREN 8)

AUTHOR

Jay Kistler, 1990, Created


Next Previous Contents