第二页
扩展界面
看看：对于硬件厂商来说，建立一个能够降低他们所出售的硬件数的标准不符合他们的利益，因此许多标准的变动非常缓慢。
现有存储系统的利用效率如何？我们是否利用了磁盘驱动器的1％，5％，25％，50％或80％的性能？就我所看到的情况而言，通常是接近5％。对于那些需要很高的IOPS（每秒输入输出）的应用程序而言，尤其如此。这种情况有许多原因，但是其中一项原因，如同我过去一再指出的那样，就是那些从应用程序到存储设备之间的资源没有得到很好的协调。除了OpenGroup已经提出的那些改变之外，还需要有一些改变来支持更好的可伸缩性。这里有一些建议：
协调整个数据路：T10的OSD（基于对象存储）就体现了这种努力，但是它还不能包括磁带或SATA磁盘驱动器，而这两者对于归档系统来说是必须的。
对文件系统元数据的通用界面的支持：OpenGroup的DMAPI只支持归档。现在还没有一个通用界面来访问今天现有的文件系统元数据，更不用说未来可能存在的元数据了。
我们需要这些改变，让我们能够进行像迁移到新系统和厂商这样的事情--这也可能是硬件厂商可能不支持这种改变的一个理由。
通用命令
今天我们有标准界面的文件系统命令，如ls -l 和find，但如果你像要看文件系统专门的归档信息，你需要用一些专门的命令来看文件系统。这些命令不提供通用的数据格式，查看文件信息的方式也不同。如果我们想要对其他的文件信息做出修改，那么我们就需要改变命令集，以便在归档系统中查看文件。为什么我们有了这些数据库，我们还是需要通过读取文件标志符（inodes）和扩展属性来访问文件数据呢？这的确很悲哀，我们必须得通过这种方式来访问文件，即使我们已经发展出能够支持所有其他搜索操作类型的数据库，我们还是得一次读取一个文件标志符和属性来读取文件元数据。
为未来做准备
我同一些有PB级存储系统的单位合作。仅仅10年前，还没有人听说过2TB的文件系统，文件大小的限制就2GB，甚至无法改变。而现在，EB级的存储系统也不远了。目前的命令和标准正在限制硬件的扩展，因此，由于数据路径扩展性的限制，我们需要购买大量的硬件。
和我合作的许多站点公开讨论对支持文件系统元数据的SSD（固态硬盘）硬件的需求。今天，相对于传统的使用内存双列直插内存模块（DIMM）SSD，现在SSD经常意味着闪存，在成本和能耗方面有许多不同。SSD的一个问题是许多文件系统本身的设计不能有效使用这种技术，而且，即使它们可以，就我所知，还没有这种技术的公司的可靠性还没有得到证实。当然，对于你的USB驱动器它能运作得很好，但是它能用于大型归档系统么？如果不能，这意味着什么？回到主机。在1970年代，IBM在MVS（多重虚存系统）解决了其中一些问题。IBM控制着这个操作系统，因此能很好的快速回应市场需求。
闪存不是问题的答案，因为它只是在伤口上贴了一个创可贴而已（治标不治本）；数据之路需要大的手术，才能提高效率、可操作性，并满足未来需求。
网友评论