NFS problems with non-ClearCase access

Depending on the NFS implementation on the non-ClearCase® host, you might encounter various problems when using non-ClearCase access.

Problems with NFS client caching

Most NFS client implementations include caches to speed up access to frequently used file data and metadata. Newer client implementations typically cache more aggressively than older ones. When the NFS client believes its cache is valid, but data in the view or VOB is inconsistent with the cached data, the client might access the wrong file from the VOB.

A common inconsistency arises when a file is checked in from another view or when the exporting view’s config spec is changed. If, as a result, the view selects a new version of a file, the NFS client might not notice the change, because it expects that any change in the name-to-file binding changes the time stamp of the directory that contains the file. In this case, the directory in the exporting view has not changed, but the file cataloged in that directory has changed versions. The NFS client might not revalidate its cached name-to-file binding until it recognizes that the directory has changed or the entry is pushed out of the cache because of capacity constraints.

Most NFS clients consider a cache to be valid for only a short period, typically 60 seconds or less. If the cache is not updated in a short time, you might be able to use one of the following methods to work around this restriction:
  • Create and remove a dummy file from the containing directory. This changes the directory time stamp, which invalidates the client’s cache and forces the client to look up the new file version. (On some platforms, this method is effective only if you do it on the remote host.)
  • Disable the client’s attribute cache (usually with the noac mount option). However, our testing indicates that this works only for some NFS V2 clients and will increase the network traffic between the NFS client and the exporting view server. If your client uses NFS V3 by default and you want to use noac, edit the mount options to request NFS V2.
  • As root, unmount the file system and then remount it. This flushes the NFS client cache for the file system. (Even if the unmount fails, it flushes the cache.)

Limit the dynamic nature of non-ClearCase access by using config specs that do not continually select new versions of files. Use label-based rules rather than the /main/LATEST rule.

Problems with NFS locking

Because non-ClearCase access does not support NFS file locking for its files, applications that require file locking do not work properly on files accessed with non-ClearCase access. Though file locking might work for view-private files on some platforms running Linux® or the UNIX® system, it might not work for VOB files. An application can hang if it retries lock requests until it can obtain a lock. It can also be subject to file corruption if it continues when it cannot obtain a lock and multiple clients are modifying the same file. If your application requires file locking, use snapshot views or the DevOps Code ClearCase Web interface to access VOB data from hosts that do not run DevOps Code ClearCase.