This chapter discusses maintenance procedures, both automatic and manual, for ClearCase VOBs and views. Invoking these procedures periodically controls the growth of these data structures.
VOB administration involves a continual trade-off between these goals:
Ensuring that all important data (and meta-data) is preserved.
Discarding data (and meta-data) that is no longer important, in order to minimize disk-space requirements.
Figure 10-1 shows how VOB storage pools and VOB databases grow in regular usage; it also lists the maintenance commands (“scrubbers”) that control growth of these storage areas.
When ClearCase is installed on a host, the root user's crontab(1) file is modified to include a daily maintenance procedure (ccase_cron.day) and a weekly maintenance procedure (ccase_cron.wk). These scripts, in turn, invoke other scripts that run the scrubber programs.
A host's daily VOB-maintenance procedure scrubs the storage pools of all VOBs whose storage directories reside on that host:
Source pools are never scrubbed automatically. Source versions are too valuable to be routinely deleted. (But see “Removing Unneeded Versions from a VOB”.)
Derived object pools are scrubbed to delete DO data containers that are no longer being used by any view (those whose reference counts are zero). This also removes the corresponding derived objects from the VOB database.
Cleartext pools are scrubbed to control their size. These pools are essentially caches; scrubbing all data containers in a cleartext pool would only affect ClearCase performance, not its correctness.
Scrubbing of storage pools is performed by the scrubber utility. Each derived object and cleartext storage pool has its own scrubbing parameters, which control how scrubber processes that pool. To change the way VOB storage pools are scrubbed on a host, you can:
Change the invocation of the scrubber utility in script /usr/atria/config/cron/scrubber_day.sh.
Change the scrubbing parameters for an individual pool, using a mkpool –update command.
See “Adjusting Storage Pool Scrubbing” for an example of modifying a pool's scrubbing parameters.
Almost every change to a VOB is recorded in the VOB database as an event record. Some event records have permanent value, such as those for the creation of elements and versions. Others, however, may not be useful at all to your organization, or may lose their value as time passes. (For example, you probably don't care about the removal of an unneeded or obsolete version label.)
A host's weekly VOB-maintenance script invokes the vob_scrubber utility, removing unwanted event records from all VOBs whose storage directories reside on that host. Each host has its own configuration file, /usr/atria/config/vob/vob_scrubber_params, which controls vob_scrubber operation; for even greater control, each VOB can have its own configuration file, with the same name. See the vob_scrubber manual page for more information.
Deletion of event records and derived objects from a VOB database by the vob_scrubber and scrubber utilities is logical, rather than physical. That is, the scrubbers do not reduce the size of any file in the VOB database subdirectory (db). Instead, they increase the amount of “free space” within these files, for use by newly-created event records and derived objects.
If you need to actually shrink a VOB's on-disk storage, use the reformatvob command, which discards all such “free space”. In general, however, we don't recommend routinely shrinking VOBs—it's usually sufficient to have maintenance procedures keep them from growing too fast.
Like any other isolated workspace, a view's private storage area tends to accumulate some “junk”: core dump files, text-editor backup files, excerpts from mail messages and source files, and so on. These view-private files can take up a significant amount of disk space. As administrator, encourage users to clean up their own private views periodically; for shared views, the cleanup task may fall to you. See “Manual Cleanup of a View”.
Users can remove derived objects from their views using standard tools, such as the UNIX rm(1) command and make clean targets in makefiles.
From an administrator's standpoint, limiting the growth of a view storage directory typically involves just one issue: removing redundant derived object (DO) data containers. When a DO is first built by clearmake or clearaudit, its data container is placed in the private storage area of the user's view. The first time the DO is winked-in to another view, the data container is merely copied, not moved, to a VOB's derived object storage pool. (Moving it might wreak havoc with user processes that are currently accessing the DO.) This leaves a redundant copy of the data container in view-private storage.
Typically, you need not do anything about these redundant copies:
In a view that is frequently used for builds, old (and potentially redundant) DO data containers are replaced by newer ones by the execution of build scripts.
There can be at most one redundant copy of each DO in a view. (Contrast this with the situation for VOBs: if the scrubber utility is never invoked, the VOB will accumulate an ever-growing number of DOs that are no longer used.)
Unless disk storage is extremely scarce, these factors may make it not worth the effort to clean up redundant data containers in view-private storage. Accordingly, ClearCase does not include any automated procedures for removing them.
If you decide that redundant DO data containers must be removed from some view's private storage area, use the view_scrubber utility. You can also use this utility to migrate the data containers of unshared (not yet winked-in) DOs to VOB storage—that is, to make the VOB(s) “pay the storage cost” instead of the view.
The following example shows how some DOs can be built, and then immediately transferred to VOB storage:
% clearmake hello <build messages> % /usr/atria/etc/view_scrubber -p hello *.o Promoted derived object "hello" Scrubbed view-resident data container for "hello" Promoted derived object "hello.o" Scrubbed view-resident data container for "hello.o" Promoted derived object "util.o" Scrubbed view-resident data container for "util.o" |
See the view_scrubber manual page for more information.
The daily and weekly ClearCase VOB-maintenance scripts automatically execute “local” supplementary scripts:
No error occurs if either of these user-supplied files does not exist. “Adjusting Storage Pool Scrubbing” includes examples of supplementary maintenance scripts.
Depending on how ClearCase is installed, the directory /usr/atria/config/cron may or may not actually be local to a particular host. If two or more hosts share the same /usr/atria/config/cron directory, you may need to have the “local” script perform conditional processing, based on the hostname. Alternatively, you can use a completely separate mechanism to invoke supplementary maintenance procedures.