Cleartext pool 是一个内部缓存，用来保存VOB中近访问过的任何类型的文本文件。只要用户访问了文本文件，ClearCase将会自动更新Cleartext pool 。访问过的文件将复制到Cleartext pool中，以便其它想要在他们的视图中访问相应文件的开发者能够快速访问它。

Derived object pool 在一个缓存目录中保存二进制文件，以便允许这些文件被其它开发这共享，通过使用一个名为wink in的ClearCase程序。这些文件可以被wink in 到开发者的视图，并不需要把二进制文件复制到开发者的工作空间，这样可以保持开发者的视图小化。关于wink in的更详细的信息可以参考IBM ClearCase用户指南，可以访问下面的链接product documentation page.。

2.2 视图结构简述
与VOB类似，视图也有一个ClearCase定义的内部的数据结构。图2显示了视图存储目录的内容。

在视图存储目录中，主要的存储区是 .s目录，它是视图的私有区域。它包含检出的文件、不共享的二进制或者目标文件，以及临时文件。视图的空间大小将主要由产生的不共享的导出的目标文件大小决定。共享的文件可以被wink in，它们不增加视图的大小。

Config_spec 是一组规则，用来定义哪些文件在开发人员视图中可见。甚至在很大的视图中，config_spec 也不会变得很大，因为它只是一些简单的用来控制视图规则的文本文件。

Db_files 包含有关视图存储目录信息的ClearCase内部元数据。

2.3 VOB和视图大小的影响
VOB维护着所有基于源代码的修改信息，随着时间推移，它的大小将变得相当大。控制VOB物理存储空间大小的机制是在VOB服务器上设置的。VOB服务器地设置主要集中在开发和Build过程上，因为在这里能收集到多的用来Build的数据。合适的配置、调整以及VOB服务器的可用性，这些都是ClearCase产品环境的基本原则。

旧的不再使用的VOB不需要保存，以便充分节约空间。主要问题在于是应该拥有一个大的VOB还是几个小的VOB，关键在于性能与易管理性的平衡。在下面的情况下，大的VOB将带来性能的瓶颈：

    大的VOB通常由很多开发人员使用，它将很可能在VOB服务器上带来网络争用问题。
    在VOB中保持大量的文件也将带来磁盘I/O资源的争用问题，因为多个视图都需要访问VOB文件用来Build或者把它们放到cleartext pool中。
    VOB增大后ClearCase将消耗更多的内存和CPU资源。

一般来说，你应该考虑把一个大的VOB按照有明确意义的方式分为几个小的VOB。如果VOB只有很少的使用率，那么它的大小不应该成为问题。另一方面，如果系统管理员的资源比较缺乏，而且只有少量的开发人员，这时使用大的VOB是有利的。

从2002版本开始，ClearCase VOB在其数据库中不再有记录数的限制。但是当VOB数据库的大小达到接近于两倍的VOB服务器的内存大小时，VOB的访问性能将开始显著下降。

3 ClearCase期望的硬件特性
选择硬盘配置和ClearCase平台时，需要考虑很多因素。例如开发组的大小、网络拓扑、地理位置分布等等，这些都将对硬件解决方案产生很大的影响。

在具体的部署建议之外，其它一些因素也是很重要的：

    高性能: 为了稳定的、可预测的时间响应。
    可靠性和可用性: 为了大的正常运行时间。
    可测量性: 为了评估将来增长的需求
    有效的支持组织: 为了支持用户采用ClearCase。