Status for Andrew DeFaria

View space

I looked into the disk space usage on the view2 server (partitions view2a, view2b and view2c0 and find the following:

View Policy and view_db.crs_file size

When you use use dynamic view and clearmake(1) to utilize build avoidance by winking in derived objects, Clearcase stores configuration records in the view's storage directory (.s):

CONFIGURATION RECORDS. The file view_db.crs_file in the .s subdirectory is actually part of the view's database, as described inthe following section. It is the part that stores the configuration records of derived objects built in the view.

...

view_db.crs_file

Stores the configuration records of nonshareable and unshared derived objects. This file resides in subdirectory .s of the view storage directory, allowing it to be remote.

Compressed copies of the configuration records are cached in a view-private file, .cmake.state, located in the directory that was current when the build started. This speeds up configuration lookup during subsequent builds in the view.

The view_db.crs_file can get fairly large over time. This is another reason why Rational says that "views should be used like Kleenex".

Recovering View Space

According to Eric J. Ostrander's ClearCase / ClearQuest pages:

Release view database disk space back to the system.

As data is collected in a view, the view's database increases in size. Commands such as view_scrubber that remove DOs from a view merely release logical space inside the view's database. That is, the disk space taken by the database does not shrink. This is true for the view-storage/db/* files and the view-storage/.s/view_db.crs_file file (which contains the derived object configuration records). To actually release that space back to the system, one needs to run recoverview twice on that view. Normally recoverview is only needed when a VOB is no longer available and the view's view-private files that once belonged to the VOB are now stranded. However, it has the added benefit that it calls reformatview, which in turn cleans up the database.

The recoverview must be run twice. The first pass releases any unused space in the database back to the system and cleans up CRs no longer attached to a DO. The second pass releases the now newly unused space (freed up in the first pass) back to the system. A third run has no affect.

An attempt to run reformatview by itself (which is actually the only part that is really needed) will result in the message "reformat not needed for view". Unfortunately, reformatview does not have a -force option, but recoverview does.

# ct recoverview -force -tag view-tag
# ct recoverview -force -tag view-tag

NOTE: Running recoverview does not affect view-private files.

WARNING! Rational recommends not being anywhere in the view-storagearea during the recoverview/reformatview (reason unknown).

Clearcase 7.0.1.0 Installation on Linux

In installing Clearcase 7.0.1.0 on Linux, Kirk and Tom were having problems getting it set up as a registry server. One problem was that they incorrectly named the config file rgy_srv.conf instead of rgy_svr.conf (I always get those wrong myself). There also seems to be an issue where there are two directories, both under /var/adm/rational/clearcase, one named rgy (where the registry is stored) and one named config (where other config files are stored). And there are additional config files related to the registry, rgy_hosts.conf and rgy_region.conf. As it seems to turn out those three files (rgy_svr.conf, rgy_hosts.conf and rgy_region.conf) need to be in both the rgy and config directories under /var/adm/rational/clearcase. Is this new for 7.0.1.0?

Turns out I was mistaken. While I was working on this so was Kirk. So our actions overlapped and effected each other. The real thing is that these rgy_*.conf files rightfully moved from the rgy directory to the conf directory for 7.0.