HP 3PAR的瘦身(Thin Provisioning，自动精简配置)技术的颗粒度是有史以来最低的，以16KB为单位，其它的技术则需要从1MB到17GB不等的颗粒度，所以3PAR在以小数据块为主的核心T1应用中能够发挥更加显著的瘦身作用。同时用ASIC芯片的好处不仅是offload(卸载)了CPU，而且在IO“击中”ASIC芯片的时候，就完成了瘦身，因此实现了实时的瘦身和回收。也就是说当OS做delete或者drop的时候，只要使用适当的命令，空间立即就被释放掉了，同时没有任何实际的IO发生。

归根到底，虚卷(Virtual Volume)相对于实卷(Physical Volume)的好处在于，若干应用的使用空间可以共享同一个Pool(池)，就是俗称的所谓“用一张10人的桌子同时请了100人吃饭”，所以最大化了空间资源的利用率，避免了频繁的磁盘扩容。同时对于开发和测试类的工作很有帮助，例如一个新的应用在测试的期间用比较小的数据集和小范围的客户群，那么它的实际空间消耗就仅限于那么一点，当逐步扩大数据量和用户范围的时候，开销自然的变大，当真正的上线之时，达到最大或者说最合适的“尺寸”，这些都不需要再手工进行调整了。而关于每个VV或者 CPG(Common Provisioning Group)的provisioning(分配)的细节可以用showvv/showcpg看到，从而产生详细的报表，在多租户的环境中，这个报表可以作为收费的依据。

不适合ThP(Thin Provisioning的缩写)的场景也有很多，比如满了(使用率80%以上)的文件系统，因为用户数众多，从高级别统计的意义上讲，有人删除文件，也有人不断的创建新文件，始终保持着FS的高占用率，那么就没有必要使用ThP;有些类型的应用持续的写新的空间，比如log(日志)和swap(交换文件)，那么空间的回收可能性接近于零;数据库没有运行在“auto-extend(自动扩展)”的模式，也就是说DB会时不时的拿一块空间过来，全部写上标记，把这块空间据为己有然后慢慢使用，这种“占有欲很强”的应用不适合用ThP。

TPVV适合的场景是大空间使用量的环境，从256MB到几十GB，太小的空间消耗就没必要用ThP了;大量的snap空间需要意味着快照所占的空间甚至会超过TPVV本身，当快照的空间达到或者超过TPVV的80%时，就不要用ThP了;使用加密卷时，即使写16K的零，加密算法也会导致内容的变化从而使ThP失效;ThP需要设置和变更策略，需要持续的监控空间使用和观察报警，对于习惯了“撒手不管”型的客户来说，这也是一种负担，不过可能也是购买驻场服务的机会。

TPVV的最小尺寸是256MB/1GB(P10000 V系列)，最大尺寸是16TB，只能增长，不能收缩，在使用TPVV的同时，应当相应配合地在主机上设置Quota(配额)。任何一个TPVV都从属于一个CPG，CPG的定义包含了：磁盘类型、转速、RAID、容量扩展单位、chunklet所在“圈位”、可靠性。之所以会有不同的CPG，是因为需要有：不同的RAID保护 / 不同的磁盘类型 / 把TPVV绑定在某些node(控制器节点)上 / 把TPVV限制在一小部分磁盘上从而避免相互的影响提高可靠性 / 完全同样属性的CPG可以起不同的名字，从而区隔不同的应用、部门、或者顺应某种管理的需要，收费时针对CPG而不是VV的报表更加实际和有针对性。当 CPG所剩的空间小于“扩展单位”的75%时，CPG就会自动扩展了，但CPG的扩展幅度是比较大的，因为这些扩展单位必须“全局条带化”到所有底层磁盘上，CPG的扩展单位可以随时在线调整，当设成0的时候，CPG就不再自动扩展了，最小和缺省的扩展单位跟node数量有关，而最大扩展单位是2TB- 256MB。