(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
\newpage
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) .
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.
Checkpoint volume modify log. This command will create a
checkpoint file
/usr/coda/spool/
<
uid
>
/
<
vol
>
@
<
mountpt
>
.
Where
<
uid
>
is your
cfs
user id,
<
vol
>
is the volume being checkpointed, and
<
mountpt
>
is the volume's mount point.
Abbreviation: ck .
Check the status of the Coda file servers. Report on servers that are down.
Check volume/name mappings.
Clear short-term priorities used for cache management.
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.
Tell venus to end a repair session on file. Useful if repair is exits without finishing the repair session.
Abbreviation: er .
Examine reintegration closure. Using cfs examineclosure will display the fixfile used to reintegrate changes that were made while operating in disconnected mode.
Abbreviation: ec
Flush entire cache. Care must be taken when using the cfs flushcache command, as flushing the cache while operating in disconnected mode may result in loss of data.
Flush objects from cache. cfs flushobject tells venus to remove the given objects from the cache.
Abbreviation: fl
Flush all data in specified volumes. Care must be taken when using the cfs flushvolume command, as flushing the cache while operating in disconnected mode may result in loss of data.
Map the given paths to Coda file ids.
Abbreviation: gf
Map fid to volume-relative path. cfs getpath will display the path for each of the given fids.
Abbreviation: gp
List access control list for each of the given directories.
Abbreviation: la
List the contents of the entire cache or the given volumes (directories).
Abbreviation: lc
Display the current status of the volume in which the directory is stored.
Abbreviation: lv
List the countents of a mount point. This command can be used to tell what volume a mount point refers to.
Create a mount point. Mount volume name at the point in the file system described by filename . If the -rw flag is set, never use the corresponding read-only volume for a volume. Otherwise, if a read-only volume exists (and the parent is also a read-only volume), use the read-only volume.
Abbreviation: mkm
Purge volume modify log. Care must be taken when using the cfs purgeml command, as it may result in loss of data.
Replay reintegration closure.
Abbreviation: rc
Remove a mount point from the file system. The volume itself is not changed.
Abbreviation: rmm
Set access control list. Sets the access control list for each id . The -clear switch clears the access control list except for the entries given on the call to cfs . The -negative switch denies the given permissions, rather than granting them. Rights are a subset of rwidlak which are read, write, insert, delete, lookup, administer, and lock respectively. See the section on File Protection in the Coda manual for more detail.
Abbreviation: sa
Truncate the RVM log at this instant.
Abbreviation: tl
Tells venus whether it should wait forever for dead file servers or not. By default, venus does not wait; it returns ETIMEDOUT. For certain batch jobs, waiting is better than not waiting.
Abbreviation: wf
List the servers that the given files reside on.
Partition your client from the Coda file servers.
Reconnect to the Coda file servers. cfs reconnect will undo the effects of a cfs disconnect .
Tell venus to write disconnect on the given volumes, or all volumes if none are provided. Write disconnected operation will fetch files from the server, but does not propagate changes back immediately.
An -age argument gives the age of the CML before it should be reintegrated. The -time arguments gives the number of seconds the sending of a reintegration fragment should take. Abbreviation: wd
Strongly connect to the servers.
Abbreviation: wr
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
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:
For use in shell scripts, the password is read from stdin. This option is also enabled when stdin is not a tty.
Test the clog-venus token passing code.
Specify the host where the authentication server is running.
Authentication mechanism, use kerberos tickets or coda password to identify yourself to the authentication server.
After obtaining a token from the authentication server, write it to a file.
Read a previously saved token from a file and present it to venus.
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
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:
Report data in absolute mode.
Probe servers every probeinterval seconds. Default is 60.
The data reported by cmon is organized under four headings: TIM, CPU, RPC, and DSK.
The TIM data is as follows:
time at which this cmon process was created.
time at which the server was last probed.
time at which the server last responded to a probe.
time at which the server process was started.
number of times contact was reestablished after a failed probe. A probe may fail due to server or network failures.
The CPU data is as follows:
relative or absolute number of seconds of system CPU time used on the server.
relative or absolute number of seconds of user CPU time (regular or niced) used on the server.
relative or absolute number of system and user seconds divided by corresponding time of accumulation.
The RPC data is as follows:
number of RPC connections.
number of workstations connected to server. Note that each instance of cmon shows up as a workstation.
relative or absolute number of RPC calls received.
relative or absolute number of RPC packets received. Includes duplicates and other bogus packets. Also includes bulk transfer packets.
relative or absolute number of packets sent. Includes retransmissions. Also includes bulk transfer packets.
bytes corresponding to pki.
bytes corresponding to pko.
The DSK data is as follows:
identity and percent usage of most full disk partition on server. The identity is the name of mount point. Names longer than 5 characters are truncated to the first 3 characters, a $ character, and the last character.
identity and percent usage of second most full disk.
identity and percent usage of third most full disk.
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
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:
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
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
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
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.
Connects to a client at IP port number port on the host named host . (For Coda clients and servers, use 1363 and 1361 respectively.)
Disconnects from; client number clientnum .
Lists the current set of connected clients.
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.
Removes the filter with identifier id on the given side of client clientnum.
Lists the filters at client clientnum.
Removes all filters from the set specified by side . side can be either in , out , or both (the default).
Terminates the program. Note that this does not clear any filters.
COMMANDLINE INVOCATIONS
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.
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.
Removes all filter from the hosts given.
blocks traffice between the hosts given.
removes all of the filters between hostname1 and hostname2 inserted by partition, or slow, or filcon.
inserts filters on hostname1 and hostname2 to control the network speed between the machines.
ARGUMENTS
Port to attatch to. This should be 1363 for a Coda client and 1361 for a server.
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
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:
Hoard distinguishes between children of a directory, which are members of the directory, descendants which are either children or descendants of childres of the directory.
Commands may be abbreviated by their first letter. Parameters in angle brackets are optional, and have default values if unspecified. The attributes parameter is specified as a string of options separated by : characters. The currently recognized options are:
assign this object the hoard priority indicated
current children of this directory will inherit its hoard status
current and future children of this directory will inherit its hoard status
current descendents of this directory will inherit its hoard status
current and future descendents of this directory will inherit its hoard status
If the uid in the clear and list commands is unspecified, the entries of all users are cleared or listed respectively. The default hoard priority is 10.
An example command file is:
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:
Enables debugging output.
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
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:
Verbose mode. Will print out information on the progress of the command.
Force update. Moves in the files even if the source files are not newer.
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
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:
verifies that object is indeed in conflict. It will print out messages to indicate whether the current repair session is for server-server conflict or local-global conflict.
For a server-server repair session, this command locks the corresponding volume and and mounts its individual replicas read-only. It will inform the users to only use the comparedirs , dorepair and removeinc commands to repair the conflict.
For a local-global repair session, both local and global replicas of object are visible at object/local (read-only) and object/global (mutable and serving as the workspace for storing the repair result for object ). You need to iterate through the current sessions local-mutations-list containing all the local updates to object and its descendants. Each operation in local-mutations-list must be accounted for and Venus maintains the current-mutation being iterated. Use the checklocal command to find out the conflict between the current-mutation and the server state. Note that not all local mutations are necessarily in conflict, and you can use the listlocal command to see all the operations in local-mutations-list . You can advance the iteration to the next operation using either the preservelocal or the discardlocal command with the former replaying the current-mutation operation on the relevant global replicas. To speed up the iteration, the preservealllocal command repeats preservelocal until the local-mutations-list is exhausted or the first replay failure. Similarly, the discardalllocal command repeats discardlocal until exhausting the local-mutations-list . You can use external tools such as emacs to make direct updates on needed replicas under object/global . Use the quit command to either commit or abort the session.
If the current session is repairing a server-server conflict, this command releases all the volume-level locks and causes the repair tool to return to the shell. If the current session is repairing a local-global conflict, this command asks you whether to commit or abort the repair session. If you answer yes, the mutations performed on the relevant global replicas will be committed to the servers. Otherwise, the repair result will be aborted as if this repair session has never happened.
prints out a help message.
Use the following commands to repair a server-server conflict:
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.
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:
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:replica < servername > < id of replica1 > < repair commands for replica1 > replica < servername > < id of replica2 > < repair commands for replica2 > and so on
Note that for the setacl command, the short form access rights of all and none can also be used.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 >
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.
compares the mounted read only replicas of a directory in conflict and if the replicas are identical it clears the inconsistency flag of the replicas. Otherwise it will inform you about the inequality of the replicas. You should run the comparedirs command to find out the cause of conflict. This command should be used only for directories. Files and symbolic links are cleared of their inconsistency with the dorepair command.
The following commands are used only for repairing local-global conflicts:
checks to see if the current-mutation being iterated by the current local-global repair session is in conflict with the server state. It displays the operator and operand (s) of the current-mutation operation and indicates whether it is in conflict with the relevant server replicas. If it is in conflict, a brief reason of the conflict is given. Note that this command does not advance the iteration of the local-mutations-list .
simply advances the iteration of the local-mutations-list of the current local-global repair session to the next operation. Use this command when the user does not want the current-mutation operation to have any effect on the repair result.
tries to replay the current-mutation of the current local-global repair session on the relevant global replicas. In other words, it will try to preserve the effect of the current mutation in the repair result. If the replay succeeds, the iteration of local-mutations-list will be advanced to the next operation. The effect of the replay is visible only on this client and not on the server until the repair result is successfully committed. If the replay fails, information about the reason of the failure will be displayed.
repeatedly performs the discardlocal command until the local-mutations-list is exhausted. Its effect is to finish the iteration and discard the effect of all the remaining mutations on the repair result.
repeatedly performs the preservelocal command until the first failure or the iteration of local-mutations-list is exhausted. This command is used if the user wants to preserve the effect of all the remaining mutation operations in the repair result.
prints out all the mutation operations in the local-mutations-list of the current local-global repair session.
If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, the global replica of object is visible at object/global . This command allows the global replica of object to be visible at the original location (pathname) of object .
If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, the local replica of object is visible at object/local . This command allows the local replica of object to be visible at the original location (pathname) of object .
If the current local-global repair session is repairing a conflict on object given as the argument to the beginrepair command, this command restore the default form of local-global conflict representation in which the local replica is visible at object/local and the global replica is visible at object/global .
The following commands existed in old versions but are no longer supported:
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).
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
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:
Name of Coda coda client to bind to. If this option is omitted, then the current host will be used.
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
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
Sets up, /usr/coda/etc/vstab , for venus to contact either Mickey, Minnie or Goofy and configures venus with a 10MB cache.Venus-setup Mickey,Minnie,Goofy 10000
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
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
is designed to be called directly by the administrator to setup a server. It performs the following tasks common to both SCM and non-SCM servers:
This script is only run if ``yes'' is given as an answer to the SCM question.
This script is only run by, vice-setup , when the machine is designated as the SCM.
This script sets up the data storage area for a Coda service.
For a detailed explanation of each question asked by the scripts, please see the chapter, ``Installing a Coda Server'' in the Coda Manual.
BUGS
Many of the highlights are:
/vice/db/services
/vice/db/hosts
to complete the setup of a non-SCM server.
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
NAME volmunge - manipulates objects within Coda.
SYNOPSIS volmunge < -adfmov > dirPrints out everything but does not cross volume boundaries.
Prints out UNIX directories, but not volume mount points.
Prints out all objects which are not volume mount points (eg UNIX files and UNIX directories); this preforms a stat() call on all non-volume objects which is ideal for forcing resolution on a volume.
Prints out those objects which are volume mount points.
Prints out those objects which are UNIX files and preforms an open() call on the file.
Prints out the volume name of a volume's mount point.
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
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:
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.
updates the histogram hg with newvalue to be entered.
provides the user with statistics for the input data. Statistics include the mean, standard deviation, and the 90% confidence interval.
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
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:
initialises the timer.
allocates storage for n entries, where n corresponds to the total number of times ti_notetime () is called.
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.
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).
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.
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.
frees the storage used by the package.
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
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
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
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
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
\newpage
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
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
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
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
\newpage
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:
is a Coda user id.
is the password to use for this ViceId .
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
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
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
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
NAME
vrlist - vrlist file specification
\newpage
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
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
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:
Turns on debugging.
Attatch to hostname to do the authentication. hostname should be the SCM .
Port to bind to. The default portal is coda_auth.
Change password. Use this to change a users vice password.
Change user information. Use this to change password and other user information.
New user. The nu option tells au to add a new password entry to the vice password database.
Delete user. The du option tells au to delete the given user from the password database.
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
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:
Tells auth2 to print log entries to the controlling tty rather than a log file.
Causes auth2 to only validate passwords. New password entries cannot be added via this server instance. Servers started with the -chk option are slave servers. There should only be one master server in the system.
Sets the server debug level. This level controls the amount of debugging information printed by the server.
Used to tell auth2 where its password file is. Typically this file is /vice/db/auth2.pw.
Specifies where the token key file auth2 should use when encrypting tokens.
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
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:
Number of seconds to sleep between polls a servers that backup thinks are down.
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
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
is created
is created
on each server is used to build the VLDB
is a list of the active servers
is the result of combining /vice/vol/VolumeList from each server
SEE ALSO
update (8), volutil (8)
AUTHOR
Puneet Kumar, 1990, Created
\newpage
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
used to find out if volume already exists
name of volume created is appended to it
SEE ALSO
cfs (1), bldvldb.sh (8), volutil (8)
AUTHOR
Puneet Kumar, 1990, created
\newpage
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:
where /vice/db/VSGDB has an entry "E0000107 foo bar gorp" in it.
To assign a predetermined Group Id, use
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
contains information on replicated volumes
name of volume created at each site is appended to it
is used to describe the replicated volumes in terms of its non-replicated members.
is used to translate the VSG address to replication sites
is used to check if volume exists
is used to assign a group id to the replicated volume
SEE ALSO
bldvldb.sh (8), volutil (8), createvol (8)
AUTHOR
Puneet Kumar, 1990, Created
\newpage
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:
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:
See passwd.coda(5).< ViceId > < Clear Password > < Other user info >
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
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
must be issued to avoid an abort.touch / < partition_path > /FTREEDB.
SEE ALSO
vicetab (5)
AUTHOR
Henry M. Pierce, 1998, Created man page
\newpage
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
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:
Lists the contents of the directory indicated by volid.vnum.unique . Each entries vnode number and uniquifier are also listed.
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.
mark a volume with a "destroyme" flag, so that the salvager will destroy it on the next serverstartup.
Print < len > bytes starting from < addr > in hex and ascii.
Display a list of all the volumes on the server. This list includes the volume index, name, number, and type.
Display all of the vnodes on either the large or small free vnode list.
Display RVM heap usage.
Display the RVM index of the given volume name or number.
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 a summary of the specified volume.
Show all of the RVM state of the specified volume.
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.
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
\newpage
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
updated by deleting the entry for the purged volume.
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
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
updated by removing the entries for the replicas of the purged volume.
updated by the remote server as a side effect of purging the volume.
updated by deleting the entry for the purged volume.
SEE ALSO
bldvldb.sh(8), purgevol(8), volutil(8)
AUTHOR
David Steere, 1990, Created
\newpage
\newpage
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:
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
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:
Sets the internal debugging level to < debug level > . This controls the amount of debugging output codasrv will generate.
Sets the number of light weight processes that will be used to handle concurrent requests.
Sets the number of internal buffers used by codasrv for the dir package.
number of large vnodes in lru cache
number of small vnodes in lru cache
stack size of LWP threads in Kbytes
interval for CallBackCheckLWP to see which clients are alive
number of times a call is retried before reporting death
default timeout for all rpcs
The interval at which shutdown is checked
number of entries in the rpc trace buffer
force a full salvage on all volumes
salvage only the headers of the volumes - currently it always does a full
The -rvm switch allows you to specify the locaction of the log device, data device, and length of the recoverable segment used by the server. This parameter is not optional.
Turn off resolution on the servers
Specify how full the log can get before it is truncated. Default is 50%
Directory replica contents will not be checked for equality at end of resolution
Suppress polling and yielding by threads that run for a long period
Do not dump in-memory copy of recoverable segment before shutdown
Do not salvage volumes on shutdown
Host where mond database is stored
Port to use when contacting the mond host.
Create an inode for a vnode if the inode cannot be found by the salvager
Optimized Stores - return to the client before sftp completes
Turn on inter/intra transaction rvm optimizations
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
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
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:
This option changes the debugging level. The higher the debug_level, the more information is printed. Maximum debugging level is 10.
This is the hostname of the control machine with which this process keeps up-to-date. Default: scm.
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.
The interval between probes, in seconds. The lower this number, the quicker the servers will be updated when a change occurs and the more cpu and network resources required. Default: 300s (5min).
This option forces a .BAK file to be kept for any file that is changed.
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
is the name of the log file for the updateclnt command. It can be viewed by using the command tail -f /vice/file/UpdateLog . It is only written if debugging has been started.
is the pid of the updateclnt process.
is the pid of the updatemon process that is keeping updateclnt running.
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
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:
This is used to increase the level of messages written to the log file.
This operand is used to specify how many lwps will be used to answer file requests. Default: 2.
This name, prefixed to all file requests, is used to limit the files that can be requested.
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
This log of the messages from updatesrv is kept in the directory specified by the -p operand on the invocation. This log file is only written when debugging is enabled.
This file contains the pid of the updatesrv process. It is kept in the directory specified on the -p operand on invocation of the command.
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
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:
Take kernel device to be the device for kernel/venus communication.
Default: /dev/cfs0
Take comma-separated host list to be the initial set of hosts to be used for volume-location requests.
Limit the size of the file cache to cache files entries.
Default: 512
Limit the size of the file cache to cache blocks 1K blocks.
Default: 8192
Number of Cache Modify Log entries
Limit the size of the volume cache to volumes entries.
Default: 128
Limit the size of the VSG cache to vsgs entries.
Default: 64
Initialize the debug level to debug level . Meaningful values are {0, 1, 10, 100, 1000}.
Default: 0
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
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
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 ]
Controls whether multicast is used or not (0
Redirects console messages to console file .
Default: /dev/console
Sets the number of RPC2 retries to RPC2 retries .
Default: 4
Sets the RPC2 timeout period to RPC2 timeout seconds.
Default: 30
Sets the SFTP window size to SFTP window size packets.
Default: 8
Sets the SFTP send ahead to SFTP send ahead packets.
Default: 4
Sets the SFTP ack point to SFTP ack point packets.
Default: 4
Initializes LEFTPAREN i.e., clears) file, volume, and VSG caches.
Enables profiling.
Number of hoard database entries.
Media that RVM resides on. Meaningful values are: 1
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.
Host where mond database is stored
Port to use when contacting the mond host.
Maximum number of threads doing prefetch ioctls
Number of worker threads.
Number of callback server threads.
Location of the venus log device.
Default: /usr/coda/LOG
Size of the log device.
Location of the venus data device.
Default: /usr/coda/DATA
Specify RDS chunk size.
Number of RDS nlists.
Turn on log optimization.
Short term cache priority weight.
Medium term cache priority weight.
Short term cache scale factor.
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
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.
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.
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.
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 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 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 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.
Dump < size > bytes starting at < address > into < file-name > .
Turn on or off timers for the given subsystem.
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 a volume to prevent write access to the volume. To other users it will appear as if the operation would time out.
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.
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).
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.
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))
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.
Print the RVM statistics for the volume < volume-ID > .
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.
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 !
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.
Print the contents of a vnode (with fid = < volumeNumber > . < vnodeNumber > . < Uniquifier > ). into < file-name > .
Bring all volumes offline and bring down the server.
Save the fileserver log output (in SrvLog.old ) and start a new SrvLog.
Turn timing on or off.
Forcibly truncate the RVM log.
Unlock a volume locked via the volutil lock command. ( volume-ID) should be in Hex
Make the file server read in a new VLDB and VRDB. The server assumes the databases to exist in /vice/db/VLDB and /vice/db/VRDB . This utility is useful for reading in new databases at non-scm machines.
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
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:
Controls what Coda Optimistic Protocol (COP) options are enabled. COP modes is interpreted according to the following bit-mask: [PIGGYCOP2 | ASYNCCOP2 | ASYNCCOP1 ]. Only some combinations are legal.
Clears internal counters used in statistics reporting.
Sets the debug level to debug level . Meaningful values are {0, 1, 10, 100, 1000}.
Enable/disables multicast (0 = ``OFF,'' 1 = ``ON'')
Enables/disables profiling (0 = ``OFF,'' 1 = ``ON'')
Shuts Venus down gracefully.
Causes Venus to dump internal counters and other statistics to its log file.
Causes Venus to move its current log file to < log-file > .old and reinitialize < log-file > .
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