VOB storage pools

The c, d, and s subdirectories of the VOB storage directory contain the VOB's storage pools. On systems running Linux or the UNIX system, a pool can be a symbolic link to a directory on another disk volume or host. On Windows®, a pool must be a subdirectory of the VOB storage directory. The storage pools in these directories hold data container files, which store versions of elements, shared derived objects, and cached cleartext. Depending on the element type, versions of an element might be stored in separate containers or might be interleaved in a single file as version-to-version deltas (differences).

Each VOB storage pool directory is created with a single subdirectory known as the default storage pool. There are three default pools.

s\sdft

Default source storage pool, for permanent storage of the contents of files under HCL VersionVault control.

c\cdft

Default cleartext storage pool, for temporary storage of the cleartext versions currently in use (for example, constructed versions of text_file elements).

d\ddft

Default derived object storage pool, for storage of promoted/shared derived objects.

You can create additional pools as needed using the Pools subnode of a VOB node of the HCL VersionVault Administration Console or the cleartool mkpool or chpool commands. Each storage pool holds data containers of one kind (source, cleartext, or DO). For more about managing storage pools, see Creating additional storage for a VOB.

Source storage pools

Each source pool holds all the source data containers for a set of file elements. A source data container holds the contents of one or more versions of a file element. For example, a single source data container holds all the versions of an element of type text_file. The type manager program for this element type handles the task of generating individual cleartext versions from deltas in the container. It also updates the source container with a new delta when a new version is checked in.

Source pools are accessed by GUIs and cleartool commands such as checkout and checkin, as well as by any program that opens a file or directory in a dynamic view (whether or not the file or directory is checked out). If a cleartext version of the element is available, it is used. If it is not available, it is constructed and stored in the cleartext pool.

Cleartext storage pools

Each cleartext pool holds all the cleartext data containers for a set of file elements. A cleartext data container holds one version of an element. These pools are caches that accelerate access to element types such as text_file and compressed_text_file, for which all versions are stored in a single container.

For example, the first time a version of a text_file element is required, the text_file_delta type manager constructs the version from the element's source data container. The version is cached as a cleartext data container (an ordinary text file) in a cleartext storage pool. On subsequent accesses, the cleartext pool is checked first by HCL VersionVault, and a new version is constructed only if the requested version cannot be found there.

Cleartext pools are periodically scrubbed to remove versions that have not been recently accessed. For more information, see Scrubbing VOB storage pools.

Derived object storage pools

Each derived object storage pool holds a collection of derived object data containers. A derived object data container holds the file system data (usually binary data) of one DO, created in a dynamic view by a build tool such as clearmake or clearaudit.

DO storage pools contain data containers only for the derived objects that have been promoted to the VOB by the winkin command. Each directory element is assigned to a particular DO storage pool. The first time a DO created within that directory is winked in, its data container is copied to the corresponding DO storage pool. The data containers for unshared and nonshareable derived objects reside in view-private storage.

As with cleartext pools, DO storage pools are periodically scrubbed to remove extraneous DOs.

Preserved database subdirectories

The root directory of any VOB that has been reformatted by the reformatvob command might include a preserved db directory that contains the VOB database as it existed before the reformat. The reformatvob command preserves the previous database by renaming it. Thus, a VOB storage directory might contain earlier (and usually unneeded) VOB database subdirectories, with names such as db.0318. If reformatvob is interrupted, it might leave a partially reformatted database with the name db.reformat.