最近的EMC-NetApp性能基准测试争议让我想到：过硬的性能件并不是唯一可能需要修正的性能基准测试种类。文件系统性能基准测试也可能会误导。
最近的EMC-NetApp性能基准测试争议让我想到：过硬的性能件并不是唯一可能需要修正的性能基准测试种类。文件系统性能基准测试也可能会误导。
过硬的性能件测试中，你可以控制时钟速度、内存、总线、BIOS（基本输入输出系统）、编译器等。但是对于文件系统来说，你可能会遇到更多的变量，因此可以控制设置的选择也就更多。
我看到过许多将文件系统A和文件系统B进行比较的性能基准测试结果。这里我不列出厂商的姓名，但是我看到过许多厂商的声明声称他们的文件系统比其他文系统要更快。我读过一些性能基准测试比较文件，而它们经常和真实的使用情况不相符合。作为一个曾经给过硬的性能件厂商进行过性能基准测试比较的人，我知道这些性能基准测试结果更多的是一种营销手段。如果是正式的采购，你会仔细读这些性能基准测试规则，并尽可能的利用各种错误和漏洞来为你的产品增光添彩。
因此，让我们来仔细看看一些文件系统性能基准测试。希望你能利用这些信息来让那些进行性能基准测试比较的公司知道我们希望性能基准测试能够反映真实世界的情况。
性能基准测试手腕和骗局
这里，我们将性能基准测试类型分为"容易的"性能基准测试和"过硬的"性能基准测试两种。容易是指设置是容易的，测试是容易的，而结果是不那么实用的。过硬的性能基准测试是容易性能基准测试的对立面–而这也是唯一能够得到有效的性能基准测试结果的方式。
容易的文件系统性能基准测试包括：
文件系统建立后的读/写性能测试：这种类型的测试中，块大小通常被选择为符合存储设置设计的最佳大小。
文件系统建立后的文件建立测试：对于其中一些这种测试，文件系统元数据是预建好的，而文件是按最优的方式建立的（在一个文件目录中按顺序建立文件，或者在每个文件目录中建立最佳数量的文件）。
文件建立测试后的文件删除测试：为了能够快速删除文件，文件被按顺序建立。
进行容易的文件系统性能基准测试测试基本上是出于两个原因。厂商不用花费大量的成本和时间就可以进行测试，而它们的结果也很容易解释给公众、营销人员和销售人员。
过硬的性能基准测试是容易性能基准测试的对立面，几乎所有的部分都要花费更长的时间，花费更多的成本，而且比较难解释。同样还是用这三个例子，这里我们看看如果使用过硬的性能基准测试，它们应该是什么样子的：
稳定碎片水平下的读/写性能测试：这需要很长的时间，因为其过程是建立文件系统，增加和删除文件，进行性能测试，接着增加和删除文件，然后再进行测试。这个过程将一直持续到文件系统测试进入稳定状态，而新的文件系统碎片不再影响测试结果为止。在我曾进行过的一些测试中，这种测试结果的性能水平可能要比容易测试的结果低99%。
使用随机建立技术和和支离破碎的元数据区域来进行文件建立测试：几乎没有人曾在非最优条件下使用具有支离破碎的元数据区域的文件系统来进行文件建立测试，但是这种情况确实对性能具有很大的影响。
基于随机建立文件及目录条件下的文件删除测试：文件是随机建立的，因此其测试时间通常要比顺序建立条件下的时间长。
我认为厂商之所以几乎不愿做过硬的性能测试的另一个原因是在碎片文件系统数据或元数据上没有一个公认的标准流程。由于在这个领域没有标准的性能基准测试，更没有公认的进行这类测试的方式，任何试图进行过硬的性能测试的厂商都可能面临对其结果的质疑，但是这种方式的测试是非常重要的。比起容易测试的结果更重要的是，在过硬的性能基准测试的观察性能中，我所看到的文件系统性能退步可能要2倍、5倍、甚至500倍于容易性能基准测试。
一种最没意义的文件系统测试就是将两个具有不同运行目标的文件系统进行比较。一个例子就是在测试中运行COW（写时复制）文件系统，并且在该文件系统让整个文件或多个文件的大小和内存相匹配，然后与其相比较的文件系统却并不使用所有内存来整合写入操作，而是一种持续将数据流入磁盘的文件系统。毫无疑问，如果文件大小小于内存，那么COW文件系统的运行速度将更快。但是，如果文件大小十倍于内存，或者是在RAID（独立磁盘冗余阵列）高速缓存情况下，而文件大小十倍于RAID高速缓存，那么猜猜看哪个文件系统更可能胜出。不会是COW文件系统，因为它现在必须消耗更多的CPU资源来寻找最老的块，并将它们写出，而其内存将一直满载更多的数据。而流文件系统在这种情况下能够更好的工作。
选择最适合你工作情况的文件系统
最早的有关日志结构文件系统（LFS）的文章是"LFS存储管理工具"，其作者是Mendel Rosenblum和John K.Ousterhout。该文章在1990年六月发表于在加州Anaheim召开的USENIX夏季技术讨论会。
建立这种文件系统的主要原因之一是他们希望解决无磁盘Sun-3工作站的宕机问题，以及减少进行fsck（文件系统检查及修复命令）的时间。我所看到的方式是，他们试图通过不检查和修复（fsck）整个文件系统来用一个软件方式解决这个过硬的性能硬件问题（系统经常宕机）。这确实是一个好主意。之后，所有人都转向日志结构文件系统，因为过硬的性能件出现问题后重启和快速运行非常重要。另一个文件系统，Reiserfts，其设计是用于满足Usenet新闻服务器上高速增加删除文件的需求，而许多文件系统的设计是为了解决一个问题或另一个问题，因为在基于块存储的设备上，不可能将文件拓扑复制到设备上，并使其足够灵活以解决数据通路中的内在延迟问题。
无论何时，当我看文件系统的时候，我会努力理解其设计目的，以及它们所想要解决的问题。如果一切符合，那么我就看它们所使用的过硬的性能件技术。现在，文件系统有许多I/O问题，比如：我正在工作的笔记本电脑需要更多的高速缓存，我的台式机需要更好的I/O性能来编辑视频，可以被高速缓存或不能高速缓存的低速和高速数据库，优化I/O以捕捉诸如高速电影片段等这样的东西，保存归档等。无论厂商对其文件系统说什么，一个文件系统不可能同时在高性能下解决所有这些问题。你可能可以用一个高度可调的文件系统、一个性能专家以及通过设置来解决其中一些问题，但肯定不是所有问题。
现在市场上有一些关于文件系统性能基准测试的高调的市场宣传语言，以我所见，没有一个性能基准测试符合真实世界的问题。我把这些性能基准测试看成是像CPU核数和GHz主频等这样的指标。有许多和核以及GHz同样重要的影响真实性能的其他因素；问题是没有人做这些测试，而这种情况我看也不会有很快改变。在你决定选择文件系统之前，要先理解你的要求，并且至少看一下性能基准测试环境以及文件系统在其中的表现。对于笔记本电脑来说，用COW文件系统来测试内存范围内的性能可能是个好主意，但是对于测试100TB大小的OLTP（联机事务处理系统）数据库来说，就不好了。
