IBM Support

About Non-ClearCase Access

Question & Answer


Question

Is there information available that provides a support perspective on the topic of Non-ClearCase Access for UNIX and Linux and explains why updates made to views are not immediately refreshed?

Cause

This document is meant to supplement the IBM Rational ClearCase Administrator's Guide to explain why updates made to views are not immediately refreshed from a Non-ClearCase access perspective.

Answer

PURPOSE

The purpose of Non-ClearCase access (using a ClearCase server running the MVFS to export using NFS a view/VOB pair) is to provide file-level access to view-private and VOB files for hosts that do not or cannot run ClearCase directly. Such hosts can use NFS access to read and write files, for example run a compiler to build software on an operating system not supported by ClearCase. However, Non-ClearCase access is an imperfect and incomplete method for access to ClearCase.

Note: For example, attempts to export an NFS mount from Server A to Server B and then export that same mount to Server C (a non ClearCase host) will not work. This is known as re-exportization and is not supported due to the way NFS currently works.

Because ClearCase does not run on the host, many product functions are not directly available--no cleartool, no clearmake, no GUIs, etc.... When you need to use ClearCase tools, you must log into a ClearCase host and run the tools there. In the case of graphical tools, you may run the tools with windows displayed back on the host.

What is available from your host is file access through that host's NFS client implementation to the view-private and VOB files and directories in a view/VOB pair. However, this access is imperfect. The imperfections typically show up in NFS client caching problems and in NFS locking problems.

CACHING

Most NFS client implementations include caches to speed up access to frequently-used file data and metadata. Newer client implementations (for example NFS version 3 or 4) typically cache more aggressively than older implementations. When the NFS client believes its cache is valid, yet something has changed in the view or the VOB which is inconsistent with the cached data, the client may access the wrong file from the VOB. One common case is when a file is checked in from another view, or the exporting view's config spec is changed. If this results in a new version of a file being selected by the view's config spec, the NFS client may not notice the change, because it expects that any change in the name-to-file binding requires a change in the file's containing directory's time stamp. In this case, the exporting view's directory has not changed, yet the file cataloged in that directory has changed versions. The NFS client does not re-validate its cached binding of name to a version of the file until it believes the directory has changed (or the entry is pushed out of the cache due to capacity constraints).

One way to work around this restriction is to create and remove a dummy file from the containing directory--this invalidates the client's cache and it will then look up the new file version.

Another way is to disable the client's attribute cache (usually with the "noac" mount option)--but beware that testing indicates this only works for some NFS version 2 clients, and that this will increase the network traffic between the NFS client and the exporting view server. If your client uses NFS v3 by default, and you wish to use "noac", then be sure to edit the mount options to request NFS version 2.

A guaranteed, but heavy-handed, way to work around this problem is to unmount and re-mount the file system on the NFS client. [An unsuccessful unmount attempt which fails because the file system is in use will flush the NFS client cache for that file system. You must have root privileges to attempt the unmount.]

LOCKING

Another imperfection arises with file locking. Some application packages use and require file locking--they will not work properly on files access via Non-ClearCase access. Non-ClearCase access does not support NFS file locking for its files. While it may work for view-private files on some brands of UNIX operating systems running the MVFS, it may not work for VOB files and it simply doesn't work at all on some operating systems. If an application package attempts to use locks, it may hang (if it insists on retrying lock requests until it can obtain a lock) or be subject to file corruption if multiple clients are modifying the same file (if the application continues when it cannot obtain a lock).

Review the IBM Rational ClearCase Administrator's Guide on the topic of Configuring Non-ClearCase Access on Linux of the UNIX system for more information.


[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"View: Dynamic","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF015","label":"IRIX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"}],"Version":"2002.05.00;2003.06.00;7.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
16 June 2018

UID

swg21133921