Linux文件系统：准备好迎接未来了吗？

Henry Newman是专业存储网站Enterprise Storage Forum的撰稿人，有着在高性能计算和存储行业27年的咨询顾问经验。

与我之前撰写的一些关于存储和技术问题的文章不同，三周之前一篇关于Linux文件系统的文章引发了人们的激烈讨论。

我本意是想联系我作为一名高性能计算存储咨询师的经验以及我对文件系统和操作系统的了解来为用户提供最佳应用方案。这与我以前所有文章的目的没有什么不同。我抽出很大一部分时间来考虑用户向我提出的技术问题。一直以来，我工作环境中的存储设备容量不小于500TB。现在我工作的站点存储容量超过了12PB，而且计划到2010年扩展到60PB。

在我看来，计算环境和大型存储环境有着本质的区别。在我工作的高性能计算环境中，大多是大型的集群（对，Linux集群）。我觉得其中有成千上万个节点，然而没有哪一个节点是使用大型（我这里所说的大型是指超过100TB的）Linux文件系统。我甚至没有发现有50TB的Linux文件系统。这并不是说这种系统不存在，只是我没有发现罢了，或者说是我从来没有听说过。

我见过的大型Linux集群是像Lustre那样的集群文件系统。Lustre采用多个ext-3/4文件系统，并且将这些系统集成为一个名字空间内。不过这篇和上篇文章讲的都不是Linux文件集群系统，而是关于容量超过100TB的Linux文件系统的应用。这也是Linux文件系统的问题所在。以下是我在Linux文件系统扩展过程中发现的两个问题：

·除非你将第一个RAID跳到分配到Superblock，否则文件系统是不能被分配到RAID条带中的。几乎所有的高性能文件系统都能自动完成这个流程，元数据区域被分配到RAID条带中，元数据通常被与其他数据隔离开分配到别的设备中，这样RAID条带就可以根据数据和元数据的保存地址来进行分配了。

·如果遇到硬件问题，例如RAID故障、因为停电等原因导致多个设备发生故障，那么仅仅对日志进行FSCK操作是不够的。如果发生这种情况，你必须FSCK整个文件系统，而不只是日志文件，一些读者也提到了这个问题。因为元数据散布于整个文件系统中并且我们必须对所有元数据进行检查，此外考虑到电力故障、RAID故障以及未发现或未修正的错误等原因，我们可能需要对RAID设备进行读-改-写操作等等繁杂的工作，因为元数据域和RAID带的应用并不一致。

这只是Linux文件系统能够在大型文件系统下成功处理高性能I/O所需要解决的两个主要问题。这并不是说你就不能在容量在100TB甚至更高的Linux文件系统中使用ext-3/4，但是高性能I/O要求数据路径上的所有系统都能占到很到比例的硬件带宽。有时候你不需要进行扩展，只要添加新的硬件设备就可以得到更多的带宽，但是这种做法会提高成本。

我需要了解的另一个问题就是具备两个插槽或者四个插槽的小型SMP系统并没有用于以上我所说的环境类型中。如果你有一个500TB的文件系统，那么你就需要向这个四路系统提供更多的带宽，或者说两个PCIe 2.0总线（理论上可以支持每秒10GB的数据传输量）。有时这些系统甚至配置了16个PCIe总线，带宽可以达到每秒10GB到20GB之间的带宽。这些系统不使用刀片，而且也不能使用刀片，因为分解大型文件系统无论从管理开支还是扩展性能上来说都是非常昂贵的。

其他问题

有用户对Google使用大型文件系统提出了质疑。我认为，Google在每个刀片节点上的文件系统规模非常小，而且他们是通过一个应用来将这些文件系统集成起来的。而且，Google的文件系统并不是一个标准的Linux产品。

有人提问说，那些需要PB级存储的用户是否应该选择块设备文件系统，而不选择链接网络的热添加文件系统，他们是否应该运行Linux文件系统，而不是将大笔的资金投入到购买大型的设备产品，再说大多数NAS文件系统还不能扩展到PB级设备。

我的回答是，现在有很有用户需要这样规模的文件系统SMP的性能。使用刀片将文件系统分解、在网络中增加管理开支，这样做提高了成本。NAS的性能并没有吸引来那些对大型归档文件作流式I/O处理的用户，他们大多采用的是基于HSM的文件系统。有人同意我的观点说，Linux文件系统可以大幅提高fsck的性能，从某种程度上来说是这样的，这些人在性能资源上投入了大笔的资金。

还有人指出，除了文件系统之外我并没有提到其他的因素，例如设备驱动器、硬件平台、应用读取模式以及运行的其他应用等。这是一个很好的问题，但我的回答是，我只是想针对Linux来解决文件系统的问题，而不是归咎于整个数据路径。

行动起来吧

以上这些都是我作为一名存储咨询师的观点和见解，也是基于我在大型站点环境的工作经验得出的。我的建议是，Linux文件系统在数十TB的环境下没有什么问题，但是最好不要应用于上百TB甚至存储容量更高的环境下。随着数据量猛增，Linux文件系统的扩展问题也将逐渐凸显出来。

如果你不同意我的观点，那么就谈谈你自己的看法吧。就拿一个500TB的ext-3/4或者其他Linux文件系统来说，在几个月时间内向其中存满多个数据流、每秒20GB的带宽条件下在一个大型SMP服务器增加或者删除文件、系统崩溃、然后对其进行fsck操作，告诉我这需要多长时间。这几个月内增加或者删除文件能够让I/O性能保持稳定吗？在一个目录下保存了100万个文件、文件系统中共有1亿个文件的情况下还能保证系统正常工作吗？

经验能够证明我的观点：在100TB环境成为常态之前需要首先解决Linux文件系统的扩展问题。从现在开始着手解决这个问题恐怕是所有Linux支持者所期望的。