早在20年前，诸如Thinking Machines和Kendall Square Research这样的公司就已经开始在研究项目中涉及到并行应用，这些公司现已终止运营，而并行应用如今却已非常普遍，不管是预测天气还是设计飞机和汽车的都无一例外的进行着并行应用。

    搜索引擎如Google、开放源代码Hadoop等，数据库如Oracle 和DB2等以及其他许多应用都属于并行应用。

    并行应用以两种不同的方式执行I/O操作：可写入一个并行文件系统，比如GPFS、Lustre 或Pan-FS；或可写入配置中每个服务器节点的本地文件系统。不过这其中存在一个问题：除了用于并行处理通信的MPI（信息传递接口）标准，以及用于并行I/O的MPI-IO标准，我们并没有其他的标准。而目前也没有任何改变的迹象，在笔者看来，现在控制着标准组织的厂商并不愿意改变现状，因为他们可以销售更多的专有解决方案，长期利润更加可观，还能锁定用户。对于用户来说，更换不同厂商的产品将会花费更多成本。

    搜索引擎的开源替代选择（例如Hadoop）具有并行通信，但是在本地文件系统中执行I/O操作。对于I/O，这不是一个很好的长远计划，因此笔者发出急切呼吁。

    为何我们都需要并行I/O

    自20世纪80年代，UNIX标准被正式通过的时候，就已经存在针对主系统调用的标准（打开、读取、写入、关闭、移动文件指针）。这些系统调用被用来执行libc；也具有了库调用标准（打开文件、读取文件、写入文件、关闭文件、重定位文件指针）。

    而20世纪90年代以来，在I/O领域中，除了少部分异步I/O系统调用标准，几乎没有任何用于用户应用的标准出现。这也意味着应用和操作系统到文件系统的接口几乎是不变的。

    目标存储在以前看来是很具希望的，它具有丰富的接口，也允许改变应用接口。但这样的希望还是未能实现，广阔的市场并没能提供基于目标存储设备（OSD）标准，不是因为它并非是一个良好的技术理念，也不是因为存储厂商不能从中获益，真正的原因是所需的投资和全球经济衰退。

    因此，应用I/O接口标准20年以来都无任何改变。

    文件系统有限的接口限制了现有的并行文件系统提高应用I/O性能。当然，许多厂商向其文件系统添加了接口功能，以使其特定文件系统实现应用优化。但每个厂商提供的应用接口都不相同，这是可以理解的，因为还不存在并行I/O或并行文件系统标准，而几年前向OpenGroup提出的建议也被忽略。并行系统厂商仍需要遵循文件系统的标准要求和相关命令，这对测试标准和I/O性能产生了重大影响。

    为什么事情会演变成现在这样，是什么导致这种状况的出现？比如，为什么Hadoop要以本地文件系统的方式执行搜索引擎？其中有一个很简单的原因：设计人员必须为性能着想而执行本地I/O。并行文件系统的并行I/O相比本地I/O要缓慢一些，因为所有管理需求都需要满足POSIX标准。即使每个应用从每个线程或任务打开一个独立文件，并行文件系统也比本地文件系统要慢。这个过程通常被称为“N to N（N任务至N文件）”。而对于“N to 1（N任务至单个文件）”，情况就会更加糟糕，甚而一些文件系统无法实现，在有成百上千或至百万的任务打开文件的时候，这是至关紧要的。

    而Hadoop执行本地I/O的另一个重要原因在于存储通信网络的成本。每个节点采用本地硬盘是符合成本效益的，而鉴于并行I/O和并行文件系统的性能问题，采用本地I/O就理所应当了。

    不管是数据库、搜索引擎、HPC（高性能计算）或者是综合应用，都会运用并行I/O。在HPC领域（一般应用MPI来进行通信），人们已经意识到并行I/O的必要性，而控制MPI的标准组织也增加了一个被称为MPI-IO的并行I/O标准。

    MPI-IO的部分功能可使小写入或读取合并为更大的写入和读取，并允许高速通信网络来处理这一合并。如果使用MPI编程模块，所有这些功能都将实现。若不具备MPI，则不能实现，这就意味着这些功能是永远都不会实现，因为MPI只用于HPC应用环境，而不会用在数据库或搜索引擎。

    适度建议

    在HPC以外的领域执行具有本地I/O的应用，可能会衍生出关于并行应用的一个鸡蛋相生问题，因为并行I/O至并行文件系统是相当缓慢的。此外，也是相当重要的一点，我们还没有并行I/O接口的标准，许多应用可以使用这些接口，并行文件系统厂商也可以为不同程度的优化而请求相应接口。

    总之，我们需要彻底重新思考I/O。ANSI T10 OSD标准虽可为I/O提供一个更新框架，算的上是一个相当不错的开端，但可惜的是，作为一个行业内标准的它已经基本结束。它在不恰当的时间发布，而存储行业也错误地忽视了重新思考I/O的重要性。即使ANSI T10 OSD成为了一个行业标准，也没有人会从语言的角度讨论并行I/O框架。C++、C、Java、数据库和其他语言都被标准POSIX 接口所束缚，而没有机会执行并行I/O。

    不可否认，大多数搜索引擎都是与本地文件系统进行通信，不仅是因为现在还不存在并行I/O标准，并行文件系统在硬件方面的成本也是其中的一个原因，但是许多搜索引擎都是通过使用每个节点的多个副本来解决节点失效的问题。该架构的刀片服务器、本地网络、同步网络、能源和冷却都需要花费成本，当它们与并行文件系统相比较的时候，可能这些成本就没那么容易被了解和理解。当然这也无关紧要，因为其中并没有标准来衡量。

    因此，笔者向包括标准组织，硬件厂商，数据库专家，语言开发者在内的团体呼吁，需要开发针对多种语言的并行I/O标准，以支持所有特性和MPI-IO等功能。

    新的并行I/O标准将需要更新POSIX，使应用写入通过I/O相关信息进入文件系统，以提高性能。这种新的生态系统也将需要调试器，从而允许用户调试并行I/O错误。这就意味着OpenGroup（控制着POSIX）将必须与ANSI委员会做一些重大的改变，就像IETF为了NFS所做的一样。

    这其中可能还需要大家的共同努力，才会最后拥有一个良好整合的I/O栈，它具有丰富的标准化接口，能够满足不同应用环境的需求（不管是数据库、搜索引擎还是HPC），因为所有的这些应用需要或可能需要并行I/O。

    或许有人会说这个设想是痴人说梦，因为存储如果不能变得易于使用和扩展，以符合带宽要求，就很可能变得毫无意义。而令人遗憾的是，这种设想要真正实现的几率与中彩票的几率差不多。