Enterprise Storage Forum的定期供稿人Henry Newman是一名行业咨询顾问，在高性能计算和存储领域拥有超过27年的经验。他经常对存储性能基准测试发表自己的观点，而上周刚刚爆发的EMC与NetApp之间的“性能战争”无疑不会被他放过，以下是文章全文。

　　最近EMC和NetApp之间的基准测试口水战让我想到：硬件基准不是唯一需要检查的基准，文件系统基准也很容易误导大家。

　　硬件可以通过时钟速度、内容、总线BIOS、编译器等控制。但是说到文件系统，你面临着更多的变数，有更多操纵的选择。

　　我认为将文件系统A和文件系统B进行比较的基准结果实在是太多了。我不会提厂商的名称，但是我看到很多厂商最近宣称他们的文件系统比其他的文件系统更快。我看到一些基准文件，它们和真正的使用情况几乎没什么关系。作为曾经为硬件厂商进行基准测试的人员，我理解基准和营销有关。如果是正式取得的话，你可以看到基准的规则，充分利用所有的错误和漏洞，让自己的产品显得更好。

　　所以让我们来看看一些文件系统基准，希望你能够利用这些信息让那些做基准测试的公司知道，我们希望基准能够反映真实世界里的使用情况。

基准测试的花招

　　我们首先把基准分为“简单”和“难”两类。“简单”的一类，我认为是一些安装简单，测试也简单，但是结果没有什么用处的基准。“难”和“简单”正好相反——只有这类基准才有意义。

简单的文件系统基准包括：

•  在文件系统创建后就进行的写/读性能测试：这种类型的测试通常使用了一些最优块大小来匹配下面的存储配置设计。
•  文件系统创建后就进行的文件创建测试：对于一些这种类型的测试来说，文件系统元数据是预先创建好的，文件按照最优方式顺序创建在某个目录下，每个目录下的文件数量为最优。
•  文件系统创建后就进行的文件移动测试：快速移动文件，文件可以按照顺序创建。

　　使用“简单”文件系统基准通常是因为两个原因。厂商不需要花多少经费和时间就可以进行这类基准测试，这种测试的结果也很容易对大众、市场和销售团队解释清楚。

　　既然“难”和“简单”相反，那么一切也都相反，这种基准测试需要的时间更长，花费更多，而且结果比较难以解释。所以使用同样的三个例子，我们来看看使用“难”的方式，应该怎样进行基准测试：

•  等到文件系统稳定之后进行的写/读性能测试：这要花费很长时间，因为创建好文件系统，增加并移动文件，性能测试开始后，要进行增加和移动文件，然后再进行测试。这个过程会一直持续下去，直到文件系统测试达到稳定的状态，增加文件系统碎片不会影响测试结果为止。从我进行的一些测试结果看，这种测试的结果可能会比“简单”测试方法的结果降低99%的性能。
•  使用任意创建技术和碎片元数据区域进行的文件创建测试：在已经有碎片元数据区域的文件系统内，以非最优方式创建文件，这种做法几乎没有人用，但是对性能却有显著的影响。
•  基于任意创建文件和目录的文件移动测试：移动任意创建的文件通常比移动连续创建的文件所花费的时间要长得多。

　　我相信厂商几乎从来不进行“难”的测试的另一个原因是因为没有标准的过程，所有人都能够就碎片文件系统数据或元数据达成一致。如果任何厂商试图这样做，都会受到怀疑，因为这个领域里没有标准的基准，这种类型的测试没有一种广为接受的方法，但是这样进行测试非常重要。这种测试比“简单”测试要重要得多，我所看到的很多运作中的系统的性能和系统标称的性能差距很大，有时候是2倍、5倍，甚至有时候能够达到500倍。

　　今天文件系统用的最没有意义的一个花招是将两个运作目标不同的文件系统放在一起对比。一个例子是COW（Copy on Write，写时拷贝）文件系统进行的一个测试，允许所有的文件进入内存。然后该厂商同另一个没有使用全部内存进行联合写操作的文件系统进行对比，这个文件系统总是将数据以流的方式传输到磁盘上。一点也不奇怪，如果文件规模小于内存，COW文件系统肯定要快得多。现在的问题是，如果文件的规模大于内存，比如达到内存的10倍，那么就算原来有RAID缓存，是否能够有10倍的RAID缓存？猜猜哪个文件系统会赢？赢家应该不是COW文件系统，因为它必须使用大量的CPU资源发现最旧的块，然后将它们写出，内存会持续不断地被数据占满。使用流技术的文件系统在这种情况下性能会好得多。

选择适合任务的文件系统

　　最初的日志结构的文件系统是Mendel Rosenblum和John K. Ousterhout提出的“The LFS Storage Manager”，该系统于1990年6月在加利弗尼亚州阿纳海姆举办的Summer '90 USENIX Technical Conference初次登场。

　　创建这个文件系统的主要原因之一是它们试图解决无盘Sun-3工作站崩溃，以及进行fsck操作时间过长的问题。我认为它们是希望解决一个硬件问题（系统经常崩溃），于是使用对软件进行了调整，不对整个文件系统进行fsck操作。这似乎是个好主意。在那之后，每个人都转向了日志结构的文件系统，因为硬件确实会崩溃，快速恢复和运行非常重要。另一个文件系统——Reiserfs的设计目标是满足Usenet新闻服务器的高速添加转移需求，很多文件系统都是为了解决这样或者那样的问题而设计的，因为基于块的存储设备不可能将文件拓扑放到设备中，它没有足够的智能解决数据路径固有的延迟问题。

　　无论什么时候，当我看到一个文件系统，都会努力去理解该系统的设计目标以及它们试图解决什么问题。我会查看它们建议的硬件技术，然后看看它们是否匹配。今天的文件系统存在着很多I/O问题，无论是我那可以严重依赖缓存笔记本还是需要好的I/O性能编辑视频桌面电脑，或者是能够或不能够使用缓存的低速和高速数据库，诸如高速电影扫描仪使用于保存存档的流I/O。无论厂商如何介绍文件系统，没有一种文件系统能够高性能地解决所有这些问题。你也许能够依靠一个高度灵活的文件系统和一个在性能和配置方面经验丰富的专家解决其中的一些问题，但绝对不能解决所有这些问题。

　　今天，在文件系统基准领域有很多言过其实的宣传，从我看到的情况看，没有一个基准能够解决现实世界里的问题。我认为这些基准不过是象CPU内核数和GHz频率一样的指标。有很多其他的因素会象内核数量和GHz一样影响真实的性能；问题是没有人做这样的测试，我认为这一局面不会很快改变。在你决定选择文件系统之前，理解你的需求，至少还应该看看基准环境，以及文件系统在做什么。针对笔记本进行内存性能测试COW文件系统也许是个不错的主意，但是它们无法测试一个100TB的OLTP数据库。