As most common problems are related to the semantical differences arising as a result of `involuntary' disconnections, this section contains some background information of why volumes become disconnected or write-disconnected. And how to get them to reconnect again.
There are several reasons why a coda client may have disconnected some or all volumes from an accessible server.
Pending reintegration. When modifications have been made to the volume in disconnected mode, the client will not reconnected the volume until all changes have been reintegrated. Also, reintegration will not occur without proper user authentication tokens. Furthermore, reintegration is suspended as long as there are objects in conflict.
The most important item here is to have a codacon process running, since it will give up-to-date information on what venus is doing. Venus will inform the user about missing coda authentication tokens, Reintegration: pending tokens for user uid. In this case the user should authenticate himself using the clog command.
Conflicts, which require us to use the repair tool, are conveyed using the local object pathname inconsistent message. Otherwise codacon should show messages about backfetches, and how many modifications were successfully reintegrated.
Access permissions. The client may also disconnect when a servers reports an error to an operation, when according to the client this is a valid operation. Causes for this are authentication failure; check tokens using ctokens and optionally obtain new tokens using clog. Or inconsistencies between the data cached on the client and the actual data stored on the server; this will reveal itself as an inconsistent object during subsequent reintegration.
Lost connections. Sometimes the client does not receive a prompt reply from an accessible server, and marks the server as dead. This will ofcourse disconnect the volume if the last server is lost. Once every five minutes, the client automatically verifies connectivity with all known servers, and can thus recover from lost connections. However, this action can also be triggered by the user by excecuting the cfs checkservers. If cfs checkservers reports that servers are unreachable, it might be interesting to check with cmon, if the server is responding at all, since we might be faced with a crashed server. When a server was considered unreachable, but is successfully contacted after cfs checkservers, reintegration will automatically start (when a user has tokens, and there are no inconsistencies).
Write-disconnected operation is used as often as weakly connected mode to describe this volume state, and they are effectively the same. This is the special situation where a client observes a weak connectivity with a server, and therefore forces the associated volumes in weakly connected mode. Weakly connected volumes postpone writing to the server to significantly reduce waiting on a slow network connection. Read operations are still serviced by the local cache and the servers, as in fully connected mode. Which is why this mode of operation is also called write-disconnected operation.
The write operations are effectively a continuous reintegration (trickle-reintegration) in the background. This mode, therefore, requires users to be authenticated and gives more chance for possible file conflicts. The following points are several reasons for write-disconnected operation.
Weak network connectivity. Venus uses bandwidth estimates made by the RPC2 communication layer to decide on the quality of the network connection with the servers. As soon as the connectivity to one of the servers drops to below the weakly connected treshhold (currently 50 KB/s), it will force all volumes associated with that server into weakly-connected mode. The cfs wr can be used to force the volumes back into fully connected mode, and immediately reintegrate all changes.
To avoid switching to weakly connected mode, use cfs strong. This way venus ignores bandwidth estimates. cfs adaptive will make venus revert to interpreting bandwidth estimates.
When the user was not authenticated, or conflicts were created during the write-disconnected operation, the user must first obtain proper authentication tokens or repair any inconsistent objects before the volume becomes fully connected again. Here again codacon is an invaluable tool for obtaining insight into the client's behaviour.
User requested write-disconnect mode. Users can ask venus to force volumes in write-disconnected mode, exchanging high consistency for significantly improved performance. By using the -age and -time flags in the cfs wd commandline, some control is given about the speed at which venus performs the trickle-reintegration. For instance, to perform the trickle-reintegrate more quickly than the default, where only mutations to the filesystem older than 15 minutes are reintegrated. You could use cfs wd -age 5, which will attempt to reintegrate all mutations older than 5 seconds.
Pending reintegration. When a volume is write-disconnected, it will stay write-disconnected until a user properly authenticates using clog.