14.10 Pool Root Check Failure

Log: ccase-home-dir\doc\examples\checkvob_sample_logs\checkvob.pool_roots

In this case, we created a new source pool, sdft2, and restored an older pool set that was missing sdft2. As a result, checkvob reports pool roots are not healthy.

Pool check failure can happen in response to various kinds of pool-related events-especially events that occur in any interval between VOB database and storage pool reference times.

Use the following procedures to diagnose and fix pool root problems.

Fixing Pool Roots: Getting Started

Try to determine the failure scenario. Use lshistory to see what has happened recently in the VOB:

• Run lshistory on any problem pools (newly created pools or renamed pools, for example).

cleartool lshistory -l pool:sdft@vob:vob-tag

• Run lshistory on the VOB itself (to find pools that have been removed, for example).

cleartool lshistory vob:vob-tag

Fixing Pool Roots: The Most Common Problems

The following sections explain how to fix common pool root inconsistencies.

For the following sections, the term skew refers to inconsistency in what the VOB database expects and what actually appears in the storage directory.

Pool Skew Caused by Addition of New Pool

Problem: An older storage directory doesn't include the newest pool (which is known to the newer VOB database). To fix the skew:

1. In the VOB storage directory, create the pool root with mkdir (or, for a remote pool on a UNIX host, using ln -s.):

2. Add a pool_id file as described in How to Re-Create a Pool's pool_id.

If the pool is a remote pool on a UNIX host, it is probably intact and needs only a new symbolic link, not a pool_id file.

Pool Skew Caused by Pool Deletion

Problem: An older database looks for a pool that has been removed from the more recent storage directory.

To fix the skew, see Pool Skew Caused by Addition of New Pool.

Pool Skew Caused by Renamed Pool

To fix the skew, rename the pool root in the storage directory so that it matches the database. The pool_id info is already correct. Only the pool's name has changed, not its identity or OID.

A More Complex Pool Skew Scenario

Problem: You removed pools sdft1 and sdft2 and redistributed their containers to new pools sdft3 and sdft4, and then renamed sdft3 to sdft2. As a result:

• Some new pools were created.

• Some pools were deleted.

• A new pool was renamed to reuse the name of a deleted pool.

The database is older than the storage directory. Therefore, from the database's perspective:

• sdft2 is has the wrong pool_id info. (The pool is a different object.)

• sdft4 is extra.

To fix the storage directory to match what is expected by the database:

• Create a sdft2 pool that has the correct identity.

• Eliminate sdft3 without losing its containers.

To fix the skew:

1. Edit the storage directory's sdft2\pool_id information to set the pool's OID to that which the database associates with sdft2.

2. Merge the extra pools into the existing pools and remove the extra pools. It is critical that the merged-in containers retain the same tree structure. For example, sdft4\0\1\leaf becomes sdft2\0\1\leaf

To merge sdft4 into sdft2:

1. Log on as the privileged user.

2. Go to the s/sdft pool directory.

3. Make sure that the pool_id file for sdft2 is not overwritten.

4. Copy the pool directory trees, making sure to preserve container ownership and access control information.

NOTE: If you fail to preserve protection data, checkvob detects and fixes the errors in the moved containers.

5. Delete the extra pool.

How to Re-Create a Pool's pool_id

The pool_id file must have a single line with the following format:

poolkind=poolkind pool_oid=pool-oid replica_uuid=replica-uuid vob_oid=vob-oid

• poolkind. s, d, or c for source, derived, cleartext respectively.

• pool-oid. The pool's OID, as determined from a command like this one:

cleartool describe -fmt '%On\n' pool:sdft2

• replica-uuid. The VOB's replica UUID (from the VOB storage directory's replica_uuid file or from lsvob -long (VOB replica UUID field))

• vob_oid. The VOB's family OID (from the VOB storage directory's vob_oid file or from lsvob -long (VOB family UUID field))