EMC TechNote: Integrating Celerra with Rational

ClearCase 2002.05.00
1 Introduction
This technical note describes the configuration environment used to test the integration of the EMC Celerra
Network Server with IBM Rational ClearCase 2002.05.00 operations. It details the configuration areas required
for a successful integration, where to get additional information, and presents information that you need to
consider when performing ClearCase 2002.05.00 operations with NFS and CIFS.
ClearCase is a software configuration management system developed by IBM Rational Software. This
distributed client/server application manages versions of files and directories by storing them in a database.
ClearCase allows you to track changes to every file and directory, and maintains histories of source code, test
suites, libraries, executables, and documentation.
The audience for this technical note is the installation and configuration specialist familiar with the Celerra and
IBM Rational ClearCase operations.

2 Integration Testing Overview

Integration testing evaluates the operation of an application in a variety of configurations, including:

Windows with CIFS protocol

UNIX with NFS protocol

The integration tests identified specific configuration requirements and integration considerations which are
documented in this Technical Note.
Testing included formal certification using ClearCase Stress Test Harness (CCST), of ClearCase v2002.05.00
(including MultiSite) with Celerra for Windows, UNIX and multi-platform environments. CCST is a ClearCase
test tool designed by IBM Rational software that was used as part of this testing.

3 Terminology
Element Files and directories that reside in ClearCase source control.
Storage pools A set of files and directories inside the VOB that can be a source pool or a cleartext pool that
contains element data; or a derived object pool that contains derived objects.
Versioned Object Base (VOB) A repository that stores versions of file elements, directory elements,
derived objects (an intermediate result of the build process under ClearCase control), and metadata.
View An object that provides a work area for one or more users. It allows you to look at a specific version of
elements, files, and directories within a database through a given set of rules.
View tag An object that allows you to access the view network-wide. The name with which users reference a
view.
VOB storage directory The top directory in a directory tree for a VOB.
View storage directory The top directory in a directory tree for a View.
VOB tag An object that enables you to view information on a specific Versioned Object Base.

Integrating Celerra with Rational ClearCase 2002.05.00

3.1 VOB Database

Each VOB is implemented as a directory tree whose top directory is called a VOB storage directory. A VOB
holds an embedded database under the db subdirectory that stores all version control structures such as elements,
branches, and versions. The actual data (all of the elements versions) are stored in the s subdirectory tree. The s
and db directories are critical directories and need a reliable storage device.
The c subdirectory tree caches the recently accessed file elements and may experience high I/O.
The d subdirectory tree stores the intermediate results of the building process and increases in size during the
development process.

3.2 View Database

Each View is also implemented as a directory tree whose top directory is called the View storage directory. The
View holds an embedded database under the db subdirectory that is used to track correspondence between VOB
and View objects. All the View private objects text editor backup files for example are stored in a private storage
area (.s subdirectory).

4 Test and Configuration Environment

Table 1 shows the configuration environment used for this application test. The EMC NAS Interoperability
Matrix contains the most up-to-date version information. For information on accessing the EMC NAS
Interoperability Matrix, refer to section 4.1, Accessing the EMC NAS Interoperability Matrix.
Table 1 Test and Configuration Environment
Component

Platform

Version

Software

Windows 2000 Server, SP2

ClearCase version 2002.05.00

ClearCase patch p2002.05.00.NT-7
ClearCase patch p2002.05.00.NT-8
ClearCase patch p2002.05.00.NT-9
ClearCase patch p2002.05.00.NT-21
ClearCase patch p2002.05.00.NT-22
MultiSite version 2002.05.00
MultiSite patch p2002.05.00.NT-1

Hardware

Solaris 8 minimum patch required: 108727-09

ClearCase version 2002.05.00

It fixes Solaris defect 4349744, which

prevents ClearCase clients from accessing
VOB or View data stored on a NAS device.

clearcase_p2002.05.00-8

Data Mover 510

5.1.9.6

multisite_p2002.05.00-1

Note: For the Windows CCST environment configuration, the following parameter value was changed on the Data
Mover: maxMpxCount=50. This parameter sets the maximum number of commands allowed without
acknowledgement in the Data Mover (i.e., Notify request). The Windows client machine uses this value to limit the
number of commands. The value is returned in the negotiate command. If this parameter is set to the default value
(127) during a Windows CCST session, the following error may occur: Insufficient system resources
exist to complete the requested service.

Integrating Celerra with Rational ClearCase 2002.05.00

4.1 Accessing the EMC NAS Interoperability Matrix

Refer to the EMC NAS Interoperability Matrix for definitive information on supported software and hardware,
such as backup software, Fibre Channel switches, and application support for Celerra network attached storage
(NAS) products.
To view the EMC NAS Interoperability Matrix:
1.

Go to http://powerlink.emc.com/.

2.

Search for NAS Interoperability Matrix.

3.

In the Sort Search Results by box, select Score.

The EMC NAS Interoperability Matrix appears in the list.

5 IBM Rational ClearCase

For instructions on installing ClearCase MultiSite, refer to the online documentation at:
http://www-306.ibm.com/software/rational/support.
Extensive testing of VOB and View creation with ClearCase was performed with the VOBs and Views storage
directories located on a Celerra. Among the ClearCase operations tested were files and directories, check in,
check out, and modification. Check of the VOB, using ClearCase commands, was used to verify the integrity of
the data and metadata. ClearCase (including MultiSite) was successfully tested using CCST.
Testing activities were performed, in the context of Celerra features such as TimeFinderTM/FS and SnapSureTM, as
well as high-availability simulation to cover component failure/failover, network disconnects, and reboots.
Celerra file system feature interaction tests also covered quotas, dynamic file system expansion, and virus
checking.

5.1 Configuration Requirements

You can install the ClearCase release area on a Celerra shared file system. For ClearCase installation
instructions, refer to Rational ClearCase Product Family Installation Guide for ClearCase MultiSite
V2002.05.00.
The Celerra was configured to host ClearCase VOBs and Views for both UNIX and Windows clients on the
same file system. Use the following operations for this configuration.
Mount and export the file system to be used for VOB(s) and View(s) storage for NFS and CIFS:
$ server_mount server_2 o accesspolicy=NATIVE,nolock,nooplock ufscc1 /ufscc1
$ server_export server_2 -o \
access=unixvobsrvr:unixviewsrvr,root=unixvobsrvr:unixviewsrvr /ufscc1
$ server_export server_2 -P cifs n ufscc1 /ufscc1
You must give root access to the ufscc1 file system for the hosts that run ClearCase VOBs and Views services.
You can configure separate file systems for VOBs and Views in order to allow access to the VOB by the VOB
servers only.
In order to help maintain the data integrity with CIFS, oplocks on the Data Mover were disabled. The options
accesspolicy=NATIVE and nolock are defaults for clients. When the same file system is used by the UNIX
and Windows clients, be sure to use accesspolicy=NATIVE to avoid the following error when creating View
or VOBs from Windows.
cleartool: Error: Failed to record hostname "winviewsrvr" in storage
directory "<Storage Directory name>". Check that root or the ClearCase
administrators group has permission to write to this directory.

Integrating Celerra with Rational ClearCase 2002.05.00

If you are working with a multiprotocol ClearCase environment, UNIX and Windows users and groups must be
mapped to the same UIDs and GIDs either by using local password and group file entries, multiple entries in
NIS, or the UNIX user management extension of a Windows Active Directory.
The following example shows how this mapping was done using local password and group files on the Data
Mover for this testing.
Note: Windows entries contain domain names; in the example below the name of the domain is capitals.

Password file example:

clearcase_albd.capitals:*:1405:2001:::
st1:<encrypted password>:4000:2000:::
st1.capitals:*:4000:2000:::

Group file example:

users.capitals::2000:
clearcase.capitals::2001:
With ClearCase for Windows, a domain group named clearcase should exist at installation time. This group is
used by the ClearCase services and cannot be used by regular users. With ClearCase for Windows, a domain
user called clearcase_albd is created at installation time. This user is used by ClearCase services and must
join the clearcase group. The clearcase_albd domain user and clearcase group must exist in the Data
Mover password and group files if you choose this method of mapping users and groups to IDs. In a multiprotocol environment, ClearCase requires the Primary Group name of ClearCase users to be the same on both
Windows and UNIX. For example, the user st1 will have its Primary Group set to users on Windows and
UNIX. Since the two platforms have different restrictions (name length and case sensitivity) choose names that
will fit both. As an alternative, you can set the variable CLEARCASE_PRIMARY_GROUP on Windows clients
with the name of UNIX Primary Group.
Note: If the user clearcase_albd , is not defined for the Data Mover, an error similar to this may occur when
creating VOBs or Views:
Failed to record hostname <VOB server name> in storage directory <Storage
Directory name>

5.2 ClearCase VOBs and Views with Celerra

You can use a Celerra in a ClearCase environment as a storage repository for VOBs and Views. For storage
configurations and devices supported by ClearCase, refer to Solution ID 26084 at:
http://www-306.ibm.com/software/rational/support/.
The following sections provide examples, using the CLI, of how to create ClearCase VOBs and Views for NFS,
CIFS, and multiprotocol environments with storage located on a Celerra. You can also perform ClearCase
operations using a GUI. Invoke the CLI tool for UNIX and Windows environments with the command,
cleartool.
Table 2 outlines the names used in these examples.
Table 2 Names Used in Examples
Object
Windows VOB server
UNIX VOB server
Windows View server
UNIX View server
Data Mover name

Name
winvobsrvr
unixvobsrvr
winviewsrvr
unixviewsrvr
dm2-ana0

Integrating Celerra with Rational ClearCase 2002.05.00

File system exported for NFS and CIFS clients by

the Data Mover
VOB tag
VOB storage directory
View tag
View storage directory
Windows tag for a UNIX VOB
Storage directory for a UNIX VOB

ufscc1
cns_vob_tag
cns_vob.vbs
cns_view_tag
cns_view.vbs
nt_vob_tag
vob_unix_cns.vbs

5.2.1 Create ClearCase VOBs and Views for NFS with Storage on Celerra
The environment for this example assumes the application has VOBs and Views stored on a Celerra on a file
system shared with NFS Version 2 or 3, using either TCP or UDP over IP.
Notes for this example:

sh shell is used.

The variable $STGPATH is set for readability.

The storage pathname must be a valid pathname reachable from every ClearCase host in the network. In this
example, /net was used.

Note: The /net is the automount point for all the Data Movers clients in the network. A UNIX share can be accessed
by /net/<hostname>. If a Data Mover or the file system is changed, the storage pathname for the VOBs and/or
Views may no longer be valid. This will require a VOB relocation operation. The simplest way to make the storage not
dependent on the name of the Data Mover or file system is to create a separate automount point. Refer to section 5.3.1
for details.

The following command creates a VOB running on the local host unixvobsrvr with storage on a Celerra:
$ STGPATH=/net/dm2-ana0/ufscc1/cns_vob.vbs
$ cleartool mkvob c test tag /cns_vob_tag host \
unixvobsrvr hpath $STGPATH gpath $STGPATH $STGPATH
The following command creates a dynamic View running on the local host unixviewsrvr with storage on a
Celerra:
$ STGPATH=/net/dm2-ana0/ufscc1/cns_view.vws
$ cleartool mkview tag cns_view_tag host unixviewsrvr hpath \
$STGPATH gpath $STGPATH $STGPATH

5.2.2 Create ClearCase VOBs and Views for CIFS with Storage Located on a
Celerra
The environment for this example assumes Views are stored on a Celerra, on a file system shared with CIFS.
Notes for this example:

The variable %STGPATH% is set for readability.

The storage pathname must be a valid pathname reachable from every ClearCase host in the network. In this
example, the UNC pathname notation was used.
The following command creates a VOB running on the local host winvobsrvr with storage on a Celerra:
C:\> set STGPATH=\\dm2-ana0\ufscc1\cns_view.vws
C:\> cleartool mkview c test tag cns_view_tag host winviewsrvr hpath \
%STGPATH% gpath %STGPATH% %STGPATH%

Integrating Celerra with Rational ClearCase 2002.05.00

The following command creates a dynamic View running on the local host winviewsrvr with storage on a
Celerra:
C:\> set STGPATH=\\dm2-ana0\ufscc1\cns_view.vws
C:\> cleartool mkview c test tag cns_view_tag host winviewsrvr hpath \
%STGPATH% gpath %STGPATH% %STGPATH%
Note: You can use the syntax in the example in a .bat file.

5.2.3 Create ClearCase VOBs for a Multiprotocol Environment with Storage on

Celerra:
With a Celerra, you can create a Windows VOB tag for an existing UNIX VOB. This allows the following
features:

Sharing of the same directories and files across UNIX and Windows environments.

Working on the same elements in both UNIX and Windows environments.

Eliminating the need for third-party NFS software on Windows and third-party CIFS software on UNIX.
The following command creates a Windows VOB tag for a UNIX VOB:
C:\>set GPATH=\\dm2-ana0\ufscc1\vob_unix_cns.vbs
C:\>set HPATH=/net/dm2-ana0/ufscc1/vob_unix_cns.vbs
C:\>cleartool mktag vob tag /nt_vob_tag host unixvobsrvr \
%HPATH% -gpath %GPATH% %GPATH%

5.3 Integration Considerations

All tests were performed using CIFS and NFS protocols. This section describes the results of the testing and
presents information you need to consider if you plan to integrate a Celerra with ClearCase 2002.05.00. Even
though some tests experienced application errors, there was no loss of data. It was sometimes necessary to restart
ClearCase services to recover from some of these errors. During the testing of Data Mover Failover and network
disconnection, it was deemed beneficial to keep VOBs and Views on separate Data Movers as it aided in the
ability to recover.

5.3.1 NFS File Access Protocols

Tests with ClearCase NFS clients were executed successfully with NFS version 2 or 3, using either TCP or UDP
over IP. Because the storage location must be reachable network-wide, the automounter was used in the
following way for convenience.
An entry in the /etc/auto_master map was specified, as is shown in the following example:
/ccstg

auto_ccstg

That entry refers to the indirect map /etc/auto_ccstg that specifies the mount point for the storage:
ccstg

dm2-ana0:/ufscc1/&

When the directory /ccstg is accessed, the file system ufscc1 on dm2-ana0 will be automatically mounted. A
Data Mover or file system name change will be done only in the auto_ccst. The VOB and Views pathnames
will not change, thus avoiding VOB/View relocation.
If a different NFS protocol version is used by the client, a different option may be specified in the auto_ccst
map. The following example shows the file system ufscc1 mounted with NFS v2 UDP.
ccstg

-proto=udp,vers=2 dm2-ana0:/ufscc1/&

Integrating Celerra with Rational ClearCase 2002.05.00

5.3.2 Network Disconnections

To investigate how an application responds, the Celerra network interface was intentionally brought down during
normal application usage. CIFS, unlike NFS, is a stateful protocol, and the interruptions caused by the network
disconnect cause the current CIFS sessions to be lost and may result in the loss of data. EMC does not
recommend that you manually disconnect the network. However, because a network disconnect would not
necessarily be a planned outage, it is not always possible to ensure file system availability during an entire
application operation.
This section describes the types of errors that occurred when Celerra network disconnections occurred in a
ClearCase environment. VOBs and Views were located on separate Data Movers and the disconnection was
executed on the Data Mover hosting the VOB storage because this is the most critical.
With NFS, when the network was disconnected during ClearCase cycles of check out, modify, and check
in commands, the operations stopped and resumed when the network became available. With CIFS, if the
interface was down for a period greater than 20 seconds, an error was generated and the ClearCase services on
the ClearCase VOB server needed to be restarted in order to resume operations.

5.3.3 Quota Limit Exceeded

To investigate how the application responds when a quota limit is exceeded, quotas were enabled on the file
system. A disk quota was intentionally set to a value lower than the disk space the user had already occupied.
The file system usage was then increased by performing ClearCase operations.
With both NFS and CIFS, when block quotas are exceeded on the file system hosting the VOB, ClearCase
services on the VOB server need to be restarted. After this, ClearCase operations can proceed normally. If the
quota limit is reached during a check out, it may be necessary to execute an undo check out before adjusting the
quota limit to a new value. Rational recommends disabling the use of quotas on file servers used for VOBs and
Views storage. This statement is included in Rational Solution Id #155410410. For information, refer to:
http://www-306.ibm.com/software/rational/support.

5.3.4 Antivirus
During testing, a file with a test virus was checked in. The virus was detected and removed by the antivirus
software. This behavior is the same as a native file server. If the antivirus software removes a VOB component
because of infection, the user may have issues that require a restore of the VOB. For this reason, EMC does not
recommend the use of antivirus software with ClearCase.

5.3.5 Read-Only Mounts/Exports

ClearCase operations were executed on a VOB with storage located on a read-only file system exported by
Celerra. Because the most common ClearCase operations imply writing to the file system, some operations may
fail. It is necessary to give the ClearCase VOBs and Views servers read and write access to the file system
exported by Celerra.

5.3.6 CIFS Security Modes

ClearCase operations were executed on a file system shared for CIFS with NT (default), UNIX, and SHARE
security modes. During this testing, it was not possible to start the ClearCase services with SHARE or UNIX
security mode on the Celerra, because ClearCase services require an authenticated Windows domain user.

Integrating Celerra with Rational ClearCase 2002.05.00

5.3.7 SnapSure and TimeFinder/FS

To investigate how an application responds to this Celerra feature, Celerra commands were intentionally
executed during normal application usage. EMC does not recommend executing these commands while
Windows/CIFS clients are running jobs. CIFS, unlike NFS, is a stateful protocol, and the interruptions from
some Celerra commands cause current CIFS sessions to be lost. A session loss could cause data loss. EMC
recommends issuing these Celerra commands only when there is no I/O activity.
For testing with TimeFinder/FS on CIFS and NFS, the fs_timefinder M refresh command was run with
no impact for ClearCase operations during file system pause/resume. If fs_timefinder R is run while
ClearCase operations are using the standard file system, ClearCase will fail during the freeze/thaw. In order to
recover the situation, you must restore a backup copy of the VOB.
ClearCase works with the TimeFinder/FS feature of the Celerra if ClearCase and TimeFinder/FS operations are
well coordinated. To have a consistent snapshot, the VOB must be locked. The amount of time the VOB is
locked (thus unavailable) may be minimized by scheduling the TimeFinder/FS operations with the locking and
unlocking of the VOB. The following scenario assumes that the fs_timefinder -S command was already
executed, and the snapshot file system (ufscc1_snap1) exists.
To establish the mirror:
1.

On the Control station, turn the mirror on: $ nas_fs -M on ufscc1_snap1

2.

Wait for the command to complete.

3.

Monitor the output of the command nas_fs -i ufscc1_snap1 and verify that the remainder value is
zero.

4.

On the VOB server, lock the entire VOB: $ cleartool lock vob:<vob-cfs-tag>

5.

Wait for the command to complete. Note that the VOB is not accessible until it is unlocked.

6.

On the Control Station, turn the mirror off: $ nas_fs -M off ufscc1_snap1

7.

Wait for the command to complete.

8.

On the VOB server, unlock the VOB: $ cleartool unlock vob:<vob-cfs-tag>

9.

Wait for the command to complete.

After the snapshot has completed, the file system ufscc1_snap1 can be mounted, potentially on a different
Data Mover, and is available for backup or other nonproduction purposes such as testing.
You can use the TimeFinder/FS feature to recover from a VOB corruption. The following example is a summary
of the main steps to take if the VOB is corrupted and the snapshot ufscc1_snap1 contains a good copy of
the VOB.
1.

On the VOB server, umount the corrupted VOB: $ cleartool umount <vob-cfs-tag>

2.

On the VOB server, lock the corrupted VOB: $ cleartool lock vob: <vob-cfs-tag>

3.

On the Control Station, restore the Snapshot Filesystem: $ /nas/sbin/rootfs_timefinder

ufscc1_snap1 -R -F

4.

Unlock and mount the VOB.

Integrating Celerra with Rational ClearCase 2002.05.00

5.

Resume ClearCase operations.

For testing with SnapSure on CIFS and NFS, the fs_ckpt refresh command was run with no impact to
ClearCase operations during file system pause/resume.
ClearCase works with the SnapSure feature of Celerra. The amount of time the VOB is unavailable during
SnapSure operations is minimal. You can further reduce this time by scheduling the fs_ckpt operations with
the lock and unlock of the VOB.
To create a checkpoint for the ufscc1 file system where the VOB resides:
1.

On the Control Station, create the metavolume to host the checkpoint: $ nas_volume -n mtv3 -c d8

2.

On the VOB server, lock the entire VOB: $ cleartool lock vob:<vob-cfs-tag>

3.

On the Control Station, create a SnapSure checkpoint: $ fs_ckpt ufscc1 -C mtv3

4.

On the VOB server, unlock the VOB: $ cleartool unlock vob:<vob-cfs-tag>

5.

Wait for the command to complete.

After the checkpoint is created, the file system, ufscc1_ckpt1, can be mounted on the same Data Mover and is
available for backup. You can use the SnapSure feature to recover from a VOB corruption. In the following
example we summarize the main steps to take if the VOB is corrupted and the snapshot ufscc1_ckpt1
contains a good copy of the VOB.
1.

On the VOB server, umount the corrupted VOB: $ cleartool umount <vob-cfs-tag>

2.

On the VOB server, lock the corrupted VOB: $ cleartool lock vob: <vob-cfs-tag>

3.

Restore the Checkpoint file system: $ /nas/sbin/rootfs_ckpt ufscc1_ckpt1 -R

4.

Unlock and mount the VOB.

5.

Resume ClearCase operations.

5.3.8 Celerra .ckpt Directory Access for NFS Clients

After a file system checkpoint is taken, it becomes available for NFS clients by means of the .ckpt directory
located at file system root level. This directory is implemented using a 64- bit file system ID. During
functionality testing with SnapSure, it was discovered that ClearCase fails when trying to access a file system
where the .ckpt directory is present. The error is:
Value too large for defined data type

This is an application issue. It is being investigated by Rational. A hotfix is available and referenced by Rational
PMR#83654. As a workaround, the .ckpt directory can be hidden from the NFS client through the following
parameter setting:
param

cfs

showChildFsRoot=0

Note: The Data Mover needs to be rebooted for this parameter to take effect.

Integrating Celerra with Rational ClearCase 2002.05.00

5.3.9 Data Mover Failover and Reboot

Celerra Data Movers achieve a high level of availability by automatically detecting and recovering from
hardware and software failures. A Data Mover can also be failed over manually as part of maintenance activity.
The response of ClearCase to a Data Mover failover was characterized by both manually failing over a Data
Mover and by automatically failing over a Data Mover with active I/O. EMC does not recommend manually
failing over a Data Mover while Windows/CIFS clients have jobs running. Unlike NFS, CIFS is a stateful
protocol, therefore the interruptions caused by the failover cause current CIFS sessions to be lost and may result
in the loss of data. EMC recommends planning a Data Mover failover for a period when there is no I/O activity.
With this application, VOBs must be locked before starting a manual failover, to avoid possibility of data loss.
On NFS, ClearCase commands completed successfully during failover and failback operations.
On CIFS, ClearCase commands failed and required ClearCase services to be restarted. If VOBs and Views were
put on the same Data Mover, a Data Mover failover resulted in data corruption. In this case, after restarting the
ClearCase services, ClearCase could not recover the corrupted VOB. A recovery was only possible by restoring
the VOB from the previous backup. If VOBs and Views were put on two different Data Movers, in case one of
the Data Movers was failed over, ClearCase commands failed and could have possibly caused VOB corruption.
After restarting the service, the error was always recoverable. Therefore, it is advisable to put VOBs and Views
on separate storage to minimize possibility of data corruption in the event of a Data Mover Failover. It is also
advisable to run frequent VOB backups as part of the enterprise backup strategy.

5.3.10 Disabling Celerra File System Cache

In order to enhance performance, Celerra Data Movers are configured, by default, to cache requests from the
clients and flush to disk in the background. In the event the file system is unavailable due to shutdown or
software failure for example, some data could be lost and the VOB could become corrupted. Although EMC is
not aware of any occurrence of this situation at a customer site, this is still a possibility.
To avoid any chance of data corruption with an application, such as ClearCase, that does not request write
through on its own, the Celerra cache should be disabled. This is done using the cifssyncwrite option
provided with the server_mount command:
$ server_mount server_2 o cifssyncwrite ufscc1 /ufscc1
Note: Consider the impact that disabling the cache has on performance. With this application, some operations will
increase their execution time considerably. Testing has shown that on average, a two times degradation of overall
performance can be expected.

A compromise would be to store only the VOB(s), which are the most critical on a file system with cache
disabled while storing the views on a file system with cache enabled (default). Figure 1 shows how different
environment variables affect the balance between performance and high availability.

Integrating Celerra with Rational ClearCase 2002.05.00

10

High Availability
QUADRANT II

QUADRANT I

-Celerra Cache
disabled for VOBs
and Views

-Celerra Data Mover

Failover

-VOBs/Views on
different Data Movers

-Celerra Cache disabled

for VOBs and enabled
for Views

-VOBs/Views on
same Datamover

-No VOB
Backups

-Celerra Cache
enabled for VOBs
and Views

QUADRANT III

QUADRANT IV

High Performance

Figure 1. Environment Scenarios

5.3.11 File System Extension

On NFS and CIFS, the file system that hosted ClearCase VOBs and Views was extended during ClearCase
operations without impact on the application. Extension of a file system, through the use of the nas_fs x
command, can be used to recover a situation where a VOB is running out of space.
For example, suppose the following error occurs when you attempt to check in a file:
cleartool> ci -nc file500M.txt
text_file_delta: Error: Trouble writing to file
/net/dm2-ana0/ufscc1/cns_vob.vbs/s/sdft/12/9/tmp_12632.3: No space left on device
text_file_delta: Error: Trouble accessing file
/net/dm2-ana0/ufscc1/cns_vob.vbs/s/sdft/12/9/tmp_12632.3: No space left on device
cleartool: Error: Type manager text_file_delta failed create_version operation.
cleartool: Error: Unable to check in file500M.txt.

The above error means the file system where the VOB storage directory resides has run out of space. A possible
solution is to use the nas_fs x command to extend the file system.
Integrating Celerra with Rational ClearCase 2002.05.00

11

On the Control Station, type:

$ nas_fs -x ufscc1 mtv11

This will extend the ufscc1 file system by the size of mtv11 that now can be used without the previous error.

6 Troubleshooting
For troubleshooting information, refer to the following online documentation:
http://www-306.ibm.com/software/rational/support/

7 Related Information
This section lists places where you can find additional information.

Celerra User Information CD received with your Celerra, or go to http://powerlink.emc.com/

and log in to Powerlink.

Rational ClearCase Administrators Guide (UNIX/Windows), Version 2002.05.00 which can be found
at: http://www-1.ibm.com/support/docview.wss?uid=pub1g126550100

Rational Solutions Knowledge Base Internet site:

http://www-306.ibm.com/software/rational/support/

8 Comments and Suggestions About this Document

Your suggestions will help us continue to improve the accuracy, organization, and overall quality of the user
publications. Please send a message to mailto:celerradoc_comments@emc.com with your opinions of this
document.

Integrating Celerra with Rational ClearCase 2002.05.00

12

Copyright 1998 - 2005 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information
is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE
INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an
applicable software license.
Trademark Information

P/N 300-001-116 A03

Integrating Celerra with Rational ClearCase 2002.05.00

13