即使一个磁盘阵列有完善的全零页回收能力，那也只是在有大量的0数据写入时才有用。这就意味着要委托服务器端必须写0填充那些不再使用的空间，而这对于服务器端来说并不是一个典型的默认的操作。因此多数操作系统都需要一个命令，像Windows里边的“sdelete –c“或者有类似NetApp SnapDrive的东西去执行这个操作，当然只是偶尔才运行一次。
还有些应用程序，像VMware ESX的数据卷，在创建新空间时就会用全零位填充，而ESX的命令“eagerzeroedthick“甚至能够将空间清除。另外，尽管还存在一些兼容性的问题，但在VMotion应用上，ESX显然正在变得越来越“精简”。ESX 4.1版本中增加的VAAI(vStorage APIs for Array Intergration)内嵌了“block zeroing”功能，可以支持多款指定的存储产品。ESX使用支持T10 ”WRITE_SAME”命令的插件(plug-in，插件既可以是定制的，亦或是通用的)给后端的磁盘阵列发信号，告知阵列去释放那些VMFS不再占用的空间。
Symantec也是率先支持自动精简配置的厂商。他们有Veritas Thin Reclamation API，该API集成在Veritas Storage Foundation产品中，可以广泛的支持大多数主流的存储阵列。它使用多种通信机制去释放不需要的空间，并且与VxFS文件系统和volume manager产品完全集成在一起。Storage Foundation还包含一个SmartMove迁移工具，该工具可以帮助精简阵列只转移那些包含实际数据的块。
精简技术在其他系统中也在同步发展。有一个标准的ATA TRIM命令，可以发送精简回收的信号，就像SCSI协议里对应的UNMAP命令一样。不过TRIM主要是用来支持固态存储。Microsoft和 Linux现在都支持TRIM，因此在未来同样能够增加对自动精简配置的支持，这些操作系统公司还可以改进其文件系统中关于存储分配和释放的机制。
越来越精简
自动精简配置技术并非没有争议，但是好处也很多。它是少数几个真正可以提升存储实际利用率的技术之一，即便问题的核心可能与技术无关。虽然精简配置技术掩饰存储空间局限性的能力以及分配空间的过程尚存某些负面的因素，但随着技术的改进，以及精简回收工作越来越自动化，未来在企业级存储领域，该技术必将成为重要的标准。
对于自动精简配置应用，我们应该关注什么?
在评估一个支持自动精简配置的存储阵列的时候，请仔细考虑下面的问题。这些问题总体上反映了我们各个方面的疑虑。注意，并不是所有情况下全部因素都必须考虑。
• 自动精简配置功能是包含在磁盘阵列的基础报价中，还是一个需要单独付费的option?
• 磁盘阵列是否支持全零页回收?以及回收进程运行的频率?
• 页面的大小或精简配置增量分配的大小是多少?
• 快照、镜像和复制操作是否支持自动精简配置?是否支持从非精简配置复制到精简配置?
• 当磁盘阵列空间写满之后会出现什么情况?报警、释放空间以及挂起写操作的流程是什么?
• 磁盘阵列是否支持WRITE_SAME命令?是否支持SCSI UNMAP或ATA TRIM命令?
• 是否有可与该磁盘阵列集成的支持“block zeroing”的VAAI插件?是否是基于T10的插件，还是为该产品系列定制的插件?
空间浪费的根源
一个DBA想：“我可能需要500GB或更多的空间给应用程序“，为了稳妥起见，他向存储管理员要了1TB的空间。而存储管理者们则保有同样的想法，为了让DBA满意的离开，因此他们给DBA分配了2个TB的存储资源。类似的故事经常用来形容存储空间利用率的糟糕状况，但这是全部真实情况吗?
在大多数企业存储环境中，低下的空间利用率可能有许多原因：
? 年度和项目预算周期制度导致了超买情况的发生，有些超买的存储空间也许永远不会用到。
? 无效的资源监测和容量计划过程并不能搞清楚真实的空间需求。
? 存储网络不够完善，导致部分空间资源无法分配给需要空间的服务器。
? 不连续的空间划拨过程导致有些空间虽然被分配，但可能永远也无法被用到。
? 操作系统和文件系统缺乏灵活性，当存储需求改变时，难以扩展或收缩。
以上列举的许多问题，使用自动精简配置都是有效的，但它也并非万能。如果采购流程和容量计划做的很差，那么精简技术的很多优点也无从发挥。如果多个 孤立的SAN和SAN之间无法访问，那么其中的空闲空间也无法利用。但这里要强调的是，一个系统即使只具备最基本的自动精简配置功能，那么对于改善闲置空 间的利用率也将大有帮助。