|
|
Every VOB has a VOB storage directory. This directory resides on the ClearCase LT server.
CAUTION: A VOB storage directory and all of its contents are created and managed by ClearCase commands and services. Never use non-ClearCase commands or utilities to alter either the contents or the protection of the VOB storage directory or any of its files or subdirectories.
A VOB's directory structure is visible when you use native operating system utilities to list the VOB storage directory and its subdirectories and files, which include the following:
.pid | A one-line text file that lists the process ID of the VOB's associated vob_server process. |
admin | A directory that contains administrative data related to the amount of disk space a VOB and its derived objects are using. Use cleartool space -vob to list this data. |
vob_oid | A one-line text file that lists the VOB's object identified (OID) expressed as a universal unique identifier (UUID). This UUID is the same for all the replicas in a VOB family (ClearCase MultiSite). This value is also stored in the VOB's database; do not change it. |
replica_uuid | A one-line text file that lists the replica UUID of this particular replica of the VOB. Different replicas created with ClearCase MultiSite have different identifiers. |
.identity | On UNIX hosts, a subdirectory whose files establish the VOB's owner and group memberships. See The .identity Directory. |
identity.sd | On Windows hosts, a binary data file that contains the security descriptor for the VOB storage directory. This security descriptor includes a Windows ACL that assigns all permissions (full control) to the VOB owner. |
groups.sd | On Windows, security descriptors of the VOB's supplementary groups. |
s | A subdirectory in which the VOB's source storage pools reside. |
d | A subdirectory in which the VOB's derived object storage pools reside. |
c | A subdirectory in which the VOB's cleartext storage pools reside. |
db | A subdirectory containing the files that implement the VOB's embedded database. See VOB Database. |
vob_server.conf | A text file read by the vob_server at startup. It contains the setting for deferred deletion of source containers; deferred deletion is activated if you have turned on semi-live backup. See the vob_snapshot_setup reference page for more information. |
.hostname | A text file that records the name of the VOB's server host. |
.msadm_acls | Stores MultiSite administration server's ACL |
The sections that follow discuss the subdirectories of the VOB storage directory.
The c, d, and s subdirectories of the VOB storage directory contain the VOB's storage pools. The storage pools in these directories hold data container files, which store versions of elements and shared binaries. Depending on the element type, the versions of an element may be stored in separate data container files or may be combined into a single structured file that contains interleaved deltas (version-to-version 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 ClearCase control. |
c\cdft | Default cleartext storage pool, for temporary storage of the cleartext versions currently in use (for example, reconstructed versions of text_file elements). |
d\ddft | Default derived object storage pool, for storage of promoted/shared derived objects. |
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 data container. It also updates the source container with a new delta when a new version is checked in.
Source pools are accessed by 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, the request to access the file element causes the cleartext to be constructed and stored in the cleartext pool.
Each cleartext pool holds all the cleartext data containers for a set of file elements. A cleartext data container holds the contents of one version of an element. These pools are caches that accelerate access to element types (text_file and compressed_text_file) for which all versions are stored in a single data container.
For example, the first time a version of a text_file element is required, the text_file_delta type manager reconstructs the version from the element's source data container. The version is cached as a cleartext data container-an ordinary text file-located in a cleartext storage pool. On subsequent accesses, ClearCase looks first in the cleartext pool. A cache hit eliminates the need to access a source pool, thus reducing the load on that pool; it also eliminates the need for the type manager to reconstruct the requested version.
Cache hits are not guaranteed, because cleartext storage pools are periodically scrubbed. (See Chapter 10, Administering VOB Storage.) A cache miss forces the type manager to reconstruct the version.
Derived objects are part of the implementation of a ClearCase feature not used by ClearCase LT. ClearCase LT VOBs contain storage pools for these objects, but the objects are never created and the pools are never used.
Each VOB has its own database, which is managed by an embedded database management system (DBMS) and implemented as a set of files in the db subdirectory of the VOB storage directory. The database stores several kinds of data:
Version-control information: elements, their branch structures, and their versions
Metadata associated with the file system objects: version labels, attributes, and so on
Event records and configuration records, which document ClearCase development activities
Type objects, which are involved in the implementation of both the version-control structures and the metadata
(UCM project VOBs only) UCM objects: folders, projects, streams, activities, components, baselines, and so on
The permanent contents of files that are under ClearCase control are stored in the source pools (.s and its subdirectories), not in the VOB database.
The db directory contains these files:
vob_db.dbd | A compiled database schema, used by embedded DBMS routines for database access. The schema describes the structure of the VOB database. |
vob_db_schema_version | A schema version file, used by embedded DBMS routines to verify that the compiled schema file is at the expected revision level. |
vob_db.d0n | Files in which the database's contents are stored. |
vista.* | Database control files and transaction logs. |
db_dumper (UNIX) | Backup copy of ccase-home-dir/etc/db_dumper. reformatvob invokes this copy of db_dumper only if it cannot invoke /usr/atria/etc/dumpers/db_dumper.num, where num is the revision level of the VOB. |
db_dumper (Windows) | A copy of ccase-home-dir\bin\db_dumper.exe. This is an executable program, invoked during the reformatvob command's dump phase. Each VOB gets its own copy of db_dumper so that it can always dump itself to ASCII files. (Typically, it needs to be dumped after a newer release of ClearCase has already been installed on the host; with this strategy, the ccase-home-dir\bin\db_dumper program in the newer release need not know about the older VOB database format.) |
vob_db.str_file | Database string file that stores long strings. |
The root directory of any VOB that has been reformatted using the reformatvob command may include a preserved db directory that contains the VOB database as it existed before the reformat. reformatvob does its work by creating a new VOB database. By default, it preserves the old database by renaming it. Thus, a VOB storage directory may contain old (and usually unneeded) VOB database subdirectories, with names like db.0318. If reformatvob is interrupted, it may leave a partially reformatted database with the name db.reformat.
On UNIX platforms, a directory named .identity on UNIX records the VOB's ownership and group membership information. Access to this directory is restricted to the VOB owner and root.
The .identity directory contains these files:
uid | The owner of this file is the VOB owner. |
gid | The group to which this file belongs is the VOB's principal group. |
group.nn | Each additional file (if any) indicates by its group membership an additional group on the VOB's group list. In addition, the file's name identifies the group by numeric ID (group.30, group.2, and so on). |
You can use the cleartool subcommands describe and protectvob to, respectively, display and if necessary change the VOB ownership information recorded in .identity or identity.sd.
NOTE: On Windows platforms, similar identity information is maintained in two files, identity.sd and groups.sd, in the VOB root directory. These files contain Windows security descriptors that describe the VOB's owner, principal group, and supplementary groups.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
