Linux文件系统：为未来做好准备了么？

DoSTOR专家观点：Henry Newman是国外专业存储网站的撰稿人，在高性能计算和存储行业从事了27年的顾问工作。

三周前，我写的一篇关于Linux文件系统的文章引起了争议性的轰动，这是十年来我在写关于存储和技术问题的文章中第一次这样。

我当时的目的是将我作为HPC（高性能计算）存储咨询师的经历和我在文件系统及操作系统上的专业知识相联系起来，为读者提供最佳的行动指南。这和我在所有其 他文章中所采取的方法是相同的。为了我的客户，我花了大部分时间来回顾存储技术问题。我所处理的安装一般是从500TB的存储容量起步。我所咨询的一个站 点中有一个目前有超过12PB的容量，而且许多站点还计划在2010年前增加到60PB。

在我的世界中，计算环境和大型存储环境有很大的不 同。在我所工作的高性能计算环境中，我经常看到大型集群（是的，Linux集群）。但是，在所有这些成百上千的节点中，我注意到，没有人实际使用大型的 --我的意思是100TB或以上--Linux文件系统。我还没有看到过50TB的Linux文件系统。这并不是说它们不存在，而是我没见过它们，也没有 听说过它们。

我所看到的Linux集群是类似于Lustre这样的集群式文件系统。Lustre目前使用许多ext3/4文件系统，并将它 们捆绑在一个单一名字的空间里。但是这篇文章和上篇文章和这些集群式文件系统没有关系，和超过100TB的Linux文件系统的实施也没有关系。这就是 Linux文件系统的麻烦所在。

我觉得Linux文件系统的扩展有两个问题。

Linux 文件系统没有和RAID（独立磁盘冗余阵列）带对齐，除非你拼凑第一个带，以便和超级锁对齐。几乎所有的大型的高性能文件系统都能够自动完成这项事情，而 元数据域则能够一直保持和RAID带的对齐。由于元数据经常是被分离到和数据不同的另一个设备上，因此RAID带可以和数据及元数据的分配相对齐。

如 果你碰到硬件问题（从RAID故障到因为电力事故等原因所导致的多个设备的硬故障），那么仅仅对日志进行FSCK（检查文件系统并修复）操作是不够的。如 果发生这种事情，那么你必须FSCK整个文件系统，而不只是日志（一些回复者指出了这个问题）。由于元数据是分布在文件系统内，因此必须检查所有的元数 据。鉴于问题的复杂性（从电力故障到RAID故障到未发现或未修正的错误），可能需要做很多的工作，而且由于元数据域和RAID带的应用并不对齐，因此需 要对RAID设备进行读－改－写操作。

这些只是许多问题中的两个。Linux文件系统要想符合大型文件系统上的高性能I/O要求，需要解决 许多问题。这并不是说你就不能使用100TB或以上的ext-3/4或其他的一些Liunx文件系统了，但是高性能I/O要求数据通路上的所有事物都能够 匹配，以便获得高比例的硬件带宽。在一些时候，你可以通过增加额外的硬件而不是通过扩展来得到带宽，但是这需要成本。

我想要澄清的另外一件 事情就是，我所讨论的这种类型的环境并不使用带两个或甚至四个插座（socket）的SMP（对称多处理器结构）系统。如果你有一个500TB的文件系 统，你经常需要更多的带宽给文件系统，而这种需求超过了四插座系统--比如说，两个PCIe 2.0总线（理论带宽为10GB/秒）--所能提供的带宽。在许多情况下，这些类型的系统使用8个甚至16个PCIe总线及10GB/秒到20GB/秒 （或更多）的带宽。这些类型的环境不使用刀片，它们也不能使用刀片，因为从管理成本的角度和扩展性能的角度来看，将大型文件系统分解开来是很不合算的。

其他问题

除了那些带过多感情色彩的回复以及个人攻击以外（不好意思，我是一个独立咨询师，并不受雇于微软或任何其他厂商，我的观点就是我自己的观点），有许多读者提出了一些很好的问题。

一位读者想知道Google是如何使用大型文件系统的。我的回答就是Google里每个刀片节点的每个文件系统都是很小的，然后通过一种应用程序来将它们组合成大的文件系统。同时，Google的文件系统并不是Linux标准发布的一部分。

一些读者注意到我没有深入阐释ext-3/4和XFS文件系统的细节。要想知道该问题的更多内容，请看我的《选择一个文件系统还是文件管理器》。

一 位读者试图了解那些面对PB级存储要求的用户是否会使用块设备文件系统，而不是使用网络型热添加（Hot-add）文件系统（我想说光调整大小这项工作就 会让人非常头疼，更不用说强制性的FSCK了），或者他们是否运行堆栈Linux文件系统，或者说它们是否在不花费时间和成本来进行重大调整的情况下运行 这种文件系统。此外，大部分的NAS（网络附加存储）文件系统都不扩展到PB级。

我的回答是，针对这种规模文件系统的SMP，我知道现在哪 些人需要这种性能。通过刀片或网络将文件系统分解，会增加管理上的花销，从而增加成本。NAS的性能并不符合那些针对大型归档进行流式I/O的人，他们几 乎都是使用基于HSM（分层存储管理）的文件系统。在Linux文件系统需要大幅改进FSCK性能这一点上，这位读者基本上同意我的观点。关于最后一点， 这些人对性能资源是有大量投资。

一些读者指出我没有提到文件系统以外的其他因素，例如设备驱动程序、硬件平台、应用程序访问模式以及其他运行中的应用程序。这是中肯的评价，但是我的回答是我只是试图解决Linux中的文件系统问题，而不是讨论整个的数据通路。

行动呼吁

这 些观点和分析是我作为一位存储咨询师而发出的，所有这些观点都是基于我在真实世界环境和超大型站点中的所见所闻。我的建议是Linux文件系统可能适用于 几十TB的系统，但是不要试图在几百TB及以上的系统中使用这种文件系统。鉴于每个地方的数据都在飞速增长，Linux文件系统的扩展性问题将随着时间越 来越明显。

如果你不同意，可以自己试试。用MKFS（建立Linux文件系统命令）建立一个500TB的ext 3-4文件系统或其他的Linux文件系统，在这个文件系统中加入多个流的数据，在几个月内用来自一个大型SMP服务器的20GB/秒带宽来添加/删除文 件，然后破坏这个系统，用FSCK来恢复它，并告诉我这个过程用了多长时间。在几个月的添加及删除文件的时间内，这个系统的I/O性能是否能保持一致？如 果在一个目录内放入一百万个文件，并在文件系统内放入1亿个文件，这时这个系统还能运作良好吗？

我猜想如此实践的结果只会证实我的观点：Linux文件系统有扩展问题，在普遍使用100TB环境之前必须要解决这些问题。只有现在心平气和地解决这些问题，Linux才会真正成为Linux支持者所期望的那样。

DoSTOR评论：对于Linux的拥趸来说，Henry的看法肯定会令他们浑身瘙痒，颇感不适，但是，却也没有人能够指出Henry的什么错误，所以，在企业的数据量普遍达到100TB之前，Linux文件系统最好尽快的跟上来。