11.5 Creating Remote Storage Pools on UNIX Hosts

On UNIX hosts, which support symbolic links to file systems on other UNIX hosts or on Network Attached Storage devices, you can distribute a VOB's storage pools to provide additional expansion capacity for VOB storage. These remote pools can be on another host or in another disk partition on the local host (Figure 16). Either way, this capability enables a VOB to circumvent the UNIX restriction that a directory tree must be wholly contained within a single disk partition. It also allows you to locate storage pools on dedicated file server hosts on which ClearCase is not installed.

There are several requirements to consider when deciding whether to use remote storage pools:

• VOB backup and recovery can be more complicated for a VOB that uses remote storage pools than for a VOB that is contained within in a single disk partition. See Backing Up a UNIX VOB with Remote Storage Pools.

• The remote location must accessible over the network by all ClearCase hosts that use the VOB. A remote host with multiple network interfaces (and multiple host names) may not work in this role.

• Unless the entire VOB storage directory is located on a Network Attached Storage device, the VOB database (db subdirectory) must be physically located on the VOB server host. You may not use a symbolic link for the VOB database directory.

Figure 16 Local and Remote VOB Storage Pools

When deciding which hosts to use for new storage pools, consider that each kind of storage pool has a different pattern of use:

• Source pools. These pools store the most precious data: checked-in versions of file elements. Traffic to and from these pools is relatively light, but data integrity is very important. We recommend that you keep source storage pools local, within the VOB storage directory. This strategy optimizes data integrity: a single disk partition contains all of the VOB's essential data. It also simplifies backup/restore procedures. These concerns typically override performance considerations, because losing a source pool means that developers must re-create the lost versions If you decide to use remote source pools, choose a robust file server for which you provide frequent, reliable data backups.

• Cleartext pools. These pools probably get the heaviest traffic (assuming that many of your file elements are stored in delta and/or compressed format). But the data in cleartext pools is expendable, because ClearCase can reconstruct it from the source pools. The ideal location for cleartext pools is a machine with a fast file system.

• Derived object pools. These pools can become quite large, depending on the number of active configurations (three new development projects, two old releases in maintenance, and so on) you need to maintain. Anticipate the storage requirements in the new pool for each active configuration; make sure the disk partition can handle the total storage requirement.

Example: Assigning All Files in a Directory to a New Pool

The following example shows how to create a new, remote source storage pool, and then reassign all the current and future elements in a particular directory to the new pool.

1. Create the new storage pool. Specify a global pathname for the remote pool that is valid for all hosts that will access the VOB.

cd /vobs/bgr
cleartool mkpool -source -ln /net/ccsvr02/ccase_pools/bgrsrc2 bgrsrc2
Comments for "bgrsrc2":
remote source storage pool
.
Created pool "bgrsrc2".

2. Reassign existing file elements to the new pool. This example reassigns all the file elements in a particular development subdirectory.

cd libbgr
cleartool find . -type f -exec 'cleartool chpool -force bgrsrc2 $CLEARCASE_PN'
Changed pool for "./Makefile" to "bgrsrc2".
Changed pool for "./errmsg.c" to "bgrsrc2".
Changed pool for "./fork3.c" to "bgrsrc2".
Changed pool for "./get.c" to "bgrsrc2".
Changed pool for "./getcwd.c" to "bgrsrc2".
.
.
Changed pool for "./stint.h" to "bgrsrc2".
Changed pool for "./strut.c" to "bgrsrc2".

3. Reassign the directory element to the new pool, too. All newly created file (and directory) elements in this directory use the new pool, also.

cleartool chpool bgrsrc2 .
Changed pool for "." to "bgrsrc2".

Example: Moving an Existing Storage Pool to Another Disk

Use the following procedure to move an existing storage pool:

1. Determine the location of the storage pool. Use the lspool command:

cleartool lspool -long d_aux@/vobs/bgr
pool "d_aux"
.
.
pool storage global pathname
"/net/ccsvr01/vobstore/bgr.vbs/d/d_aux"

2. Lock the VOB. Any new shared DOs are not being placed in the storage pool while you are working on it:

cleartool lock vob:/vobs/bgr
Locked versioned object base "/net/ccsvr01/vobstore/bgr.vbs".

3. Copy the contents of the storage pool. The storage pool is a standard UNIX directory. You can copy its contents to a new location using cp, rcp, tar, or other commands. For example:

rlogin ccsvr01
mkdir -p /vobstore_2/DO_pools
cp -r /vobstore/bgr.vbs/d/d_aux /vobstore_2/DO_pools

4. Replace the old storage pool with a symbolic link. Move the old storage pool aside; then create the link in its place.

cd /vobstore/bgr.vbs/d
mv d_aux d_aux.MOVED
ln -s /net/ccsvr01/vobstore_2/DO_pools/d_aux d_aux

Be sure the text of the symbolic link is a globally valid pathname to the new storage pool location.

5. Unlock the VOB.

cleartool unlock vob:/vobs/bgr
Unlocked versioned object base "/net/ccsvr01/vobstore/bgr.vbs".

6. Remove the old storage pool. When you have verified that the storage pool is working well in its new location, you can remove the old pool:

rm -fr /vobstore/bgr.vbs/d/d_aux.MOVED

NOTE: If a VOB-tag exists for the VOB in a Windows region, you need to re-create that VOB-tag to account for the relocated storage pool. See Windows Tags for UNIX VOBs with Symbolically Linked Storage.