重大变化：从打孔机制到应用程序数据块

NFS(即网络文件系统)算得上是计算发展史上最为成功的两大文件协议之一。从20世纪80年代的NFSv2到20世纪90年代深入人心的NFSv3，再到如今最新的NFS4.1标准——如果大家对NFSv4.1与pNFS(并行NFS)还不熟悉，那么不妨马上了解一下——该协议的开发目的是为了满足用户需求以及数据访问与处理方面的不断变化。

数据存储业务迎来了爆炸式增长。根据IDC公司的调查，2010年中全世界范围内售出的开放式系统存储容量接近1EB(即1000PB)。而2011年中一个季度所售出的的存储容量就超过了2007年全年的总和。这样的数据增长幅度无疑令人惊讶，那么是什么样的需求推动了这种增长呢?显然，我们所能看到的、对存储消费行为推动力最大的趋势正是近年来虚拟化与云计算的兴起。二者都使海量数据在管理及处理方面变得更为简便。

上述类型的需求也同时促使NFS标准根据新情况做出又一轮修改：NFSv4.2也就随之诞生。NFSv4.1与pNFS相较于NFSv3，在安全性与可扩展性方面提升明显，管理机制也有了长足进步。NFSv4.2还在最新展望中承诺为NFSv4.1用户提供期待已久的多种功能——这些功能将令NFS不仅扮演“日常”协议的角色，更将成为一套虚拟化数据中心内部应用程序的首选分布式文件协议。

服务器端副本

虚拟化意味着计算的移动化趋势。不再被局限于固定地点的固定物理硬件，操作系统与应用程序能够以无缝方式人一台服务器转移到另一台。但每套虚拟机在运作中都离不开主数据与辅助数据，这些数据在计算平台发生转换时也需要同时进行迁移。如今，客户端需要从源数据服务器处读取数据，并将这些数据直接转写到另一套目的数据服务器中，这种三路式联网结构使得数据副本带来潜在的成本支出与不必要的迁移行为。

服务器端副本(简称SSC)机制完全消除了复制操作这一过程。相反，它会根据客户端要求从一台数据服务器上读取完整的文件乃至文件目录，并通过客户端将这些内容上传至另一台数据服务器，也就是说SSC允许目标服务器与源服务器之间直接通信。客户端负责管理复制流程，但并不涉及数据的具体迁移工作。数据在不同的数据服务器之间直接传输，而SSC则消除了过去那些令人头痛的高维护成本以及对带宽要求极严的服务器-客户端-服务器通路。另外，复制操作由于网络原因发生拥堵的可能性也大幅降低。

空间预留保障

每当面临数据存储空间不足的情况，就拿块硬盘填充进去，这样的处理方式其实面临着一大根本性障碍，即：每块硬盘的购置、运行及管理都会在一定程度上提高运营成本。许多存储系统管理员都已经敏锐地意识到，用户常常会高估自己所需要的存储容量;而且高估的程度往往超乎想象。多年以来，人们通过一系列高效技术创建起一整套巨大的虚拟存储池，而构成这一庞大体系的正是无数小型物理存储系统。

自动按需配置作为上述技术中的一员，为用户提供了大量可直观查看的存储空间。虽然这种做法目前可谓司空见惯，但这种做法其实并不能完全应对快速增长的使用环境。举例来说，两位用户在查看时可能发现自己还有50%的剩余空间：但实际上他们双方都没有那么多容量可用。

NFSv4.2中的空间预留保障功能将彻底扭转这一局势，无论是否采用按需配置策略，特定文件将始终拥有最大程度的可用空间。

打孔

尽管对特定类型数据的处理已经令人满意，并保证了终端用户始终能够根据需求获得足够的存储空间，但上述保障功能常常会大幅度拉低硬盘存储机制的利用效率，导致管理员们的优化努力沦为泡影。

举例来说，当管理程序创建一个虚拟磁盘文件时，它通常会尝试为文件分配预留空间，这样的虚拟机执行操作的过程中就不会发生分配冲突类错误。应用程序中的这类文件往往实际体积为零，这种情况必然导致I/O性能与存储效率的大幅走低。

为了支持更高的存储效率，NFSv4.2推出了一套专为稀疏文件排布打造的支持技术。这就是俗称的“打孔”机制，即将文件中已被删除或未被使用的部分送回存储系统的空闲容量池中(如图一所示)。

 
图一：按需配置方案与打孔方案

按需配置方案移除了为那些永远不会真正需要的存储行为保留的空间，而真正的空闲容量就能够为广大用户所使用。NFSv4.2的打孔方案则更进一步，通过对拥有预留空间的文件进行频繁扫描找出无用数据，并将其预留空间释放出来。而客户端所查看到的结果并无变化：NFSv4.2能够以透明化方式正确反馈剩余空间情况。

应用程序数据块(简称ADB)

应用程序数据块(简称ADB)延用了打孔机制中的零体积数据块概念，支持应用程序将各种功能性模块写入数据块。举例来说，管理程序或数据库应用程序通过向虚拟机镜像或数据库中写入监控模块以提供复杂的数据破损检查功能。ADB允许这类应用程序在某个单独文件中对这些数据块进行定义，而NFSv4.2则能够利用一套经过大幅度简化的映射对其加以存储，最终达到节约空间的目的。这事实上是一种消除重复数据的管理方式。

让我们举个简单的例子。大家的应用程序可能会以利用十六进制字符串0xDEADBEEF写入数据块的方式对文件进行初始化。按理来说，初始化过程应该需要对文件中每一个数据块都写入以上内容。但ADB能够从中“找到”规律，注意到该映射内数据块存在的目的在于初始化，并决定不向块中写入内容。

当数据块接收到一条读取请求时，存储系统能够检查对应文件的映射，并认定需要查询的目标为初始化数据块，进而自动将0xDEADBEEF这一结果发送至应用程序。显然返回的结果能够满足应用程序的需求，同时整个过程中没有涉及任何额外操作，这就显著节约了存储空间与I/O性能。

有了这项功能，NFSv4.2将能够迅速高效地为数据存储初始化节约空间;创建大型数据库或是虚拟机镜像的任务现在也完全能够通过一次操作就彻底搞定。

应用程序I/O提示

随着数据流通量的不断飙升，I/O量自然也是水涨船高;与此同时，采用缓存或SSD的分层存储系统也逐步令传统的高速DRAM与低速硬盘之间的效率冲突趋于缓和。NFSv4.2为应用程序创造了一套通向底层存储系统的数据通信访问模式。举例来说，数据的读取是具备一定先后顺序的，因此应该将读取放在第一位。而有些数据的读取及写入过程往往会重复多次，因此考虑利用缓存保存这些常用数据。接下来，有些数据写入比较频率、但读取次数很少，所以要保证这类数据不会进入缓存。

那么这一整套机制什么时候才会投付使用呢?

NFSv4.2规范很可能于今年3月份获得批准，而客户端及服务器供应商要花多长时间才能将这套机制部署到位，就完全取决于作为用户的我们支持这一新技术的力度啦。

这就又带来一个问题：你还在用NFSv3吗?如果答案是肯定的，你所失去的不仅仅是NFSv4、NFSv4.1以及pNFS所拥有的那么多先进功能，更是无缘邂逅雄心勃勃、技术先进的NFSv4.2。至于原因嘛，只有一点——为了提高安全性，从NFSv3到NFSv4的升级中包含了一系列本质性“改造”，因此NFSv3无法与NFSv4的后续版本直接衔接。

尽管存在上述问题，不过距离NFSv4.2真正面世还有一段时间，大家不妨把握最后的机会，在新项目中尽管采用NFSv4及更新的协议，以准备迎接NFS家族中这位了不起的新成员。