(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
The Coda file system expands the local file system hierarchy to include shared files much like the Sun Network File System and the Andrew File System . Figure XXX below shows the users view of the file system hierarchy on a machine with all three types of file systems.
Data sharing in Coda, like that in Andrew, is supported by a distributed file system that appears as a single large subtree of the local file system on each workstation. This subtree is identical on all workstations. Thus, processes on two different workstations can read and write files in this subtree just as if they were running on a single timesharing system with the difference that processes on the different workstations see changes only when files are opened and closed. Familiarity with AFS is helpful when learning about Coda.
This chapter introduces essential Coda commands. For more details on these commands, refer to their man pages.
Once you are logged in to your workstation, you need to get a Coda authentication token by running the clog program. clog will prompt you for your Coda password and use it to get a token from the authentication server . This token will expire in about 25 hours. After the token expires, you must use clog to authenticate for another 25 hours. The following in an example of running clog twice. The first time, the wrong password was entered:
% clog Password: Invalid login (RPC2_NOTAUTHENTICATED (F)) % clog Password: %
To see your newly acquired token, use ctokens . This will display the tokens and their expiration time for your UID.
% ctokens Tokens held by the Cache Manager: UID=2534 : [Expires Mar 19 10:50]
Use the cpasswd command to change your Coda password. As with passwd , cpasswd will prompt for your current password, then ask you to enter a new password twice.
% cpasswd Changing password for raiff Old password: New password for raiff: Retype new password: Password changed, it will be in effect in about 1 hour
You can "log out" of Coda by using the cunlog command to tell venus to forget your tokens. Once you run unlog , you will have the same privileges as an anonymous Coda user until you acquire a new authentication token.
Coda provides a close approximation to UNIX protection semantics. An access control list (ACL) controls access to directories by granting and restricting the rights of users or groups of users. An entry in an access list maps a member of the protection domain into a set of rights. User rights are determined by the rights of all of the groups that he or she is either a direct or inderect member. In addition to the Coda access lists, the three owner bits of the file mode are used to indicate readability, writability, and executability. You should use chmod (1) to set the permissions on individual files. Coda rights are given as a combination of rlidwka where:
Coda also has negative rights, which deny access. Any of the normal rights listed above can also be negative.
Access control lists are managed with the cfs command through the listacl and setacl options. These commands can be abbreviated as la and sa respectively. To see the access control list of any directory in a Coda file system, use cfs la . The following example displays the current directorys ACL:
% cfs la .
System:AnyUser rl
raiff rlidwka
The displayed list, shows that the user "raiff" has all of the access rights possible on the directory and that the group "System:AnyUser" has read and lookup privileges. System:AnyUser is a special Coda group that includes all users.
A second example shows another group, System:coda. Anyone who is a member of the group, will have the groups access rights:
% cfs la /coda
System:coda rlidwka
System:AnyUser rl
Use cfs sa to change or set a directorys access control list. Options to cfs sa include -negative to assign negative rights to a user and -clear to clear the access list completely before setting any new access rights. You can also use all or none to specify all rights or no rights respectively. To remove System:AnyUsers access to the current directory, you would issue the following command:
% cfs sa . System:AnyUser none
To give System:AnyUser read and lookup rights, use:
% cfs sa . System:AnyUser rl
To deny rights to a user, use the -negative switch:
% cfs sa -negative . baduser rl
% cfs sa -negative . baduser none
If all of the servers that an object resides on become inaccessable, then the client will use the cached copy of the object (if present) as a valid replica. When the client does this, it is operating in disconnected mode .
Disconnected mode may be the result of a network failure, or it could be the result of removing a laptop from the network. If you make sure all of the files you want to use are cached on your laptop, you can travel with it and access your files as if you were still on the network.
Unfortunately, a cache miss while operating in disconnected mode is not maskable, and you will get a connection timed out error message. Coda allows you to mark or hoard files with caching priorities to help keep the ones you want in the cache.
When you are in disconnected mode, you may want to checkpoint the modify log that Coda keeps of which directories have changed. Use cfs checkpointml to do this. Checkpointing the modify log will ensure that changes you have made will not be lost if the system crashes. Coda uses this modify log when it reintegrates with the servers.
Coda also supports low bandwidth access over SLIP. You can use this to periodically reintegrate and cache new files when you are on a trip.
When you reintegrate after operating in disconnected mode, watch your codacon or run the command:
% tail -f /usr/coda/etc/console
This file will let you know if the reintegration was successful. If it was not, then the files that you modified will be put in a tar file in /usr/coda/spool/ < uid > . Reintegration fails, for example, when you modified a file in disconnected mode and someone else also modified that file on the servers. Section XXX has more on reintegration.
Coda allows you to advise the cache manager, venus , of critical files that it should try to keep in the cache. You indicate the relative importance of the files by assigning priorities to them. This is known as hoarding . Venus maintains an internal hoard database of these files. Hoarding a file helps to ensure that it will be available when operating in disconnected mode. See the hoard (1) man page for information on hoard files and sections XXX and XXX of this document for an example of how to set up your hoard database. A convenient way of setting up your hoard database is by creating a file with commands for the hoard program. This file is known as a hoard file .
As a result of Codas optimistic replica management, object replicas can conflict on different servers. A conflict arises when the same object is updated in different partitions of a network. For instance, suppose a file is replicated at two sites (say, serverA and serverB). If these two sites become partitioned and a user on each side of the partition updates the file (userA updates the file on serverA while userB updates the file on serverB), the file will be in conflict when the partition ends. Conflicts may also arise at the end of disconnected operation.
Coda guarantees conflict detection at the first request for that object when both servers are accessible. When a conflict is detected, Coda attempts to perform automatic conflict resolution. In simple cases, the conflict will be resolved automatically, a process which is transparent to the user except for a time delay in accessing the object. However, in more difficult cases, automatic conflict resolution fails and the object is marked in conflict . File system calls on an object which is in conflict fail with the same error code as if the object were a dangling, read-only symbolic link (usually, ENOENT). The conflict must be resolved by a user with appropriate access to the object. To help users resolve conflicts, Coda provides a repair tool which is discussed in Section XXX .