XFS 最初是由 Silicon Graphics，Inc. 于 90 年代初开发的。那时，SGI

发现他们的现有文件系统(existing filesystem，EFS)正在迅速变得不适应当时激烈的计算竞争。为解决这个问题，SGI

决定设计一种全新的高性能 64 位文件系统，而不是试图调整 EFS在先天设计上的某些缺陷。因此，XFS 诞生了，并于 1994 年随

IRIX 5.3 的发布而应用于计算。它至今仍作为 SGI 基于 IRIX

的产品(从工作站到超级计算机)的底层文件系统来使用。现在，XFS 也可以用于 Linux。XFS 的 Linux

版的到来是激动人心的，首先因为它为 Linux

社区提供了一种健壮的、优秀的以及功能丰富的文件系统，并且这种文件系统所具有的可伸缩性能够满足最苛刻的存储需求。

到目前为止，选择合适的下一代 Linux 文件系统一直很简单。那些只寻求原始性能的人通常倾向于使用

ReiserFS，而那些更关心数据完整性特性的人则首选 ext3。然而，随着 XFS 的 Linux

版的发布，事情突然变得令人困惑。尤其是，对于 ReiserFS 是否依然是下一代文件系统性能方面的佼佼者，人们开始感到疑惑。

最近，我进行了一系列测试，试图比较 XFS、ReiserFS 和 ext3

在原始性能方面的优劣。在与您分享该结果之前，理解以下事实很重要：该结果只着重比较了在单处理器系统上，系统负载较轻的情况下，常规文件系统的性能趋势，它并

不是衡量某一个文件系统是否比另一个文件系统“更好”的绝对尺度。尽管如此，我的结果应该可以帮助您形成一些概念，那就是：哪个文件系统可能最适于某个特定任务。再次声明，不应该将我的结果视为结论性的；最好的测试总是：在每个文件系统上运行您的特定应用程序，以观察它是如何执行的。

在测试中，我发现 XFS 通常是相当快的。在大文件操作方面，XFS

在所有测试中一直处于领先地位，这是意料之中的，因为其设计者花了数年时间设计和调整它，以便能够极出色地完成此类任务。我还发现 XFS

有一个单点性能缺陷：它删除文件不是很快；在这一方面，ReiserFS 和 ext3 轻易地胜过了它。据 Steve Lord(SGI

的文件系统软件总工程师)说，刚编写完一个补丁来解决该问题，并且不久将可以使用该补丁。

除此以外，XFS 的性能非常接近 ReiserFS，并在大多数测试指标上都超过了 ext3。XFS 最佳表现之一在于：象

ReiserFS 一样，它不产生不必要的磁盘活动。XFS

设法在内存中缓存尽可能多的数据，并且，通常仅当内存不足时，才会命令将数据写到磁盘时。当它将数据清仓(flushing)到磁盘时，其它

IO 操作在很大程度上似乎不受影响。相反，在

ext3(“data=ordered”缺省方式)下，将数据清仓到磁盘时，将导致许多额外寻道，甚至还会引起某种不必要的磁盘抖动(thrashing)(取决于

IO 负载)。

我的性能和调整测试主要是关于将 RAM 磁盘中未压缩的内核源文件 tar

包(tarball)抽取到要测试的文件系统，然后递归地将新源文件树复制到同一文件系统中的一个新目录中。XFS

对这类任务执行得很好，尽管，最初 XFS 性能比 ReiserFS 略差一点。然而，在调整了测试 XFS 文件系统的

mkfs.xfs 和 mount

选项以后，当处理诸如在内核源文件树中的中等大小的文件时，XFS 执行效率比 ReiserFS

略好一点。但这不包括删除操作；至少目前，ReiserFS 和 ext3 删除文件要比 XFS 快得多。

XFS

在哪些方面可以给您提供哪种性能，对于这一点，希望我的测试结果有助于您形成总的概念；我的测试结果显示，如果需要操作大文件，XFS

文件系统是您最好的选择。对于小文件和中等大小的文件，如果您使用一些能够增强性能的选项创建和挂装 XFS 文件系统的话，它可以与

ReiserFS 匹敌，有时甚至比 ReiserFS 更快。在“data=journal”方式下的 ext3

提供了良好性能，但是它很难获得一致的性能数据，原因在于，ext3

将先前测试中的数据清仓到磁盘所使用的方式，具有明显的不规律性，这将导致某种磁盘抖动。

在 USENIX '96 上刊载的文章“Scalability in the XFS Filesystem”中(请参阅本文后面的

参考资料)，SGI 工程师解释：他们设计 XFS 的主要思想只有一个，那就是：“考虑大东西”。确实，XFS

的设计消除了传统文件系统中的一些限制。现在，让我们研究 XFS 幕后一些有趣的设计特性，正是这些设计特性使这一点成为可能。

当创建 XFS

文件系统时，底层块设备被分割成八个或更多个大小相等的线性区域(region)。您可以将它们想象成“块”(chunk)或者“线性范围(range)”，但是在

XFS

术语中，每个区域称为一个“分配组”。分配组是唯一的，因为每个分配组管理自己的索引节点(inode)和空闲空间，实际上，是将这些分配组转化为一种文件子系统，这些子系统正确地透明存在于

XFS 文件系统内。

那么，XFS 到底为什么要有分配组呢？主要原因是，XFS 使用分配组，以便能有效地处理并行

IO。因为，每个分配组实际上是一个独立实体，所以内核可以 同时与多个分配组交互。如果不使用分配组，XFS

文件系统代码可能成为一种性能瓶颈，迫使大量需求 IO

的进程“排队”来使索引节点进行修改或执行其它种类的元数据密集操作。多亏了分配组，XFS

代码将允许多个线程和进程持续以并行方式运行，即使它们中的许多线程和进程正在同一文件系统上执行大规模 IO 操作。因此，将 XFS

与某些高端硬件相结合，您将获得高端性能而不会使文件系统成为瓶颈。分配组还有助于在多处理器系统上优化并行 IO

性能，因为可以同时有多个元数据更新处于“在传输中”。

分配组在内部使用高效的 B+ 树来跟踪主要数据，譬如空闲空间的范围和索引节点。实际上，每个分配组使用 两棵

B+ 树来跟踪空闲空间；一棵树按空闲空间的大小排序来存储空闲空间的范围，另一棵树按块设备上起始物理位置的排序来存储这些区域。XFS

擅长于迅速发现空闲空间区域，这种能力对于最大化写性能很关键。

当对索引节点进行管理时，XFS 也是很有效的。每个分配组在需要时以 64 个索引节点为一组来分配它们。每个分配组通过使用 B+

树来跟踪自己的索引节点，该 B+ 树记录着特定索引节点号在磁盘上的位置。您会发现 XFS 之所以尽可能多地使用 B+ 树，原因在于

B+ 树的优越性能和极大的可扩展性。

当然，XFS 也是一种日志记录文件系统，它允许意外重新引导后的快速恢复。象 ReiserFS 一样，XFS

使用逻辑日志；即，它不象 ext3 那样将文字文件系统块记录到日志，而是使用一种高效的磁盘格式来记录元数据的变动。就 XFS

而言，逻辑日志记录是很适合的；在高端硬件上，日志经常是整个文件系统中争用最多的资源。通过使用节省空间的逻辑日志记录，可以将对日志的争用降至最小。另外，XFS

允许将日志存储在另一个块设备上，例如，另一个磁盘上的一个分区。这个特性很有用，它进一步改进了 XFS 文件系统的性能。

象 ReiserFS 一样，XFS 只对元数据进行日志记录，并且在写元数据之前，XFS

不采取任何专门的预防措施来确保将数据保存到磁盘。这意味着，使用 XFS(就象使用

ReiserFS)时，如果发生意外的重新引导，则最近修改的数据有可能丢失。然而，XFS 日志有两个特性使得这个问题不象使用

ReiserFS 时那么常见。

使用 ReiserFS

时，意外重新引导可能导致最近修改的文件中包含先前删除文件的部分内容。除了数据丢失这个显而易见的问题以外，理论上，这还可能引起安全性威胁。相反，当

XFS 日志系统重新启动时，XFS 确保任何未写入的数据块在重新引导时

置零。因此，丢失块由空字节来填充，这消除了安全性漏洞 ― 这是一种好得多的方法。

现在，关于数据丢失问题本身，该怎么办呢？通常，使用 XFS 时，该问题被最小化了，原因在于以下事实：XFS 通常比

ReiserFS

更频繁地将暂挂元数据更新写到磁盘，尤其是在磁盘高频率活动期间。因此，如果发生死锁，那么，最近元数据修改的丢失，通常比使用

ReiserFS 时要少。当然，这不能彻底解决不及时写数据块的问题，但是，更频繁地写元数据也确实促进了更频繁地写数据。

研究一下 延迟分配这个 XFS 独有的特性，然后我们将结束关于 XFS 的技术概述。正如您可能知道的，术语

分配(allocation)是指：查找空闲空间区域并用于存储新数据的过程。

XFS 通过将分配过程分成两个步骤来处理。首先，当 XFS 接收到要写入的新数据时，它在 RAM

中记录暂挂事务，并只在底层文件系统上 保留适当空间。然而，尽管 XFS 为新数据保留了空间，但

它却没有决定将什么文件系统块用于存储数据，至少现在还没决定。XFS

进行拖延，将这个决定延迟到最后可能的时刻，即直到该数据真正写到磁盘之前作出。

通过延迟分配，XFS 赢得了许多机会来优化写性能。到了要将数据写到磁盘的时候，XFS

能够以这种优化文件系统性能的方式，智能地分配空闲空间。尤其是，如果要将一批新数据添加到单一文件，XFS 可以在磁盘上分配一个

单一、相邻区域来储存这些数据。如果 XFS

没有延迟它的分配决定，那么，它也许已经不知不觉地将数据写到了多个非相邻块中，从而显著地降低了写性能。但是，因为 XFS

延迟了它的分配决定，所以，它能够一下子写完数据，从而提高了写性能，并减少了整个文件系统的碎片。

在性能上，延迟分配还有另一个优点。在要创建许多“短命的”临时文件的情况下，XFS

可能根本不需要将这些文件全部写到磁盘。因为从未给这些文件分配任何块，所以，也就不必释放任何块，甚至根本没有触及底层文件系统元数据。

传输带宽

XFS

能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中，其吞吐量最高可达7GB每秒，对单个文件的读写操作，其吞吐量可达4GB每秒

1. xfs_admin: 调整 xfs

文件系统的各种参数 2.xfs_copy: 拷贝 xfs

文件系统的内容到一个或多个目标系统(并行方式) 3.xfs_db: 调试或检测 xfs

文件系统(查看文件系统碎片等) 4.xfs_check: 检测 xfs

文件系统的完整性 5.xfs_bmap: 查看一个文件的块映射 6.xfs_repair: 尝试修复受损的 xfs

文件系统 7.xfs_fsr: 碎片整理 8.xfs_quota: 管理 xfs

文件系统的磁盘配额 9.xfs_metadump: 将 xfs 文件系统的元数据 (metadata)

拷贝到一个文件中 10.xfs_mdrestore: 从一个文件中将元数据 (metadata) 恢复到 xfs

文件系统 11.xfs_growfs: 调整一个 xfs

文件系统大小(只能扩展) 12.xfs_logprint: print the log of an XFS

filesystem 13.xfs_mkfile: create an XFS

file 14.xfs_info: expand an XFS

filesystem 15.xfs_ncheck: generate pathnames from i-numbers for

XFS 16.xfs_rtcp: XFS realtime copy

command 17.xfs_freeze: suspend access to an XFS

filesystem 18.xfs_io: debug the I/O path of an XFS filesystem

xfs_admin: 调整 xfs 文件系统的各种参数

xfs_copy: 拷贝 xfs 文件系统的内容到一个或多个目标系统(并行方式)

xfs_db: 调试或检测 xfs 文件系统(查看文件系统碎片等)

xfs_check: 检测 xfs 文件系统的完整性

xfs_bmap: 查看一个文件的块映射

xfs_repair: 尝试修复受损的 xfs 文件系统

xfs_fsr: 碎片整理

xfs_quota: 管理 xfs 文件系统的磁盘配额

xfs_metadump: 将 xfs 文件系统的元数据 (metadata) 拷贝到一个文件中

xfs_mdrestore: 从一个文件中将元数据 (metadata) 恢复到 xfs 文件系统

xfs_growfs: 调整一个 xfs 文件系统大小(只能扩展)

xfs_logprint: print the log of an XFS filesystem

xfs_mkfile: create an XFS file

xfs_info: expand an XFS filesystem

xfs_ncheck: generate pathnames from i-numbers for XFS

xfs_rtcp: XFS realtime copy command

xfs_freeze: suspend access to an XFS filesystem

xfs_io: debug the I/O path of an XFS filesystem

具体应用：

查看文件块状况: xfs_bmap -v sarubackup.tar.bz2

查看磁盘碎片状况: xfs_db -c frag -r /dev/sda1

文件碎片整理: xfs_fsr sarubackup.tar.bz2

磁盘碎片整理: xfs_fsr /dev/sda1

ext4 和 XFS 在mysql应用的性能测试：

下图是ext4 vs xfs文件系统的对比测试结果数据，横坐标是测试模式，纵坐标是测试耗时，越小越好。

从结果来看：

1. 初始化模式下，ext4性能并没有比xfs来得高

2. 随机读写模式下，ext4性能比xfs将近高一倍

3. 其他测试模式中，ext4和xfs性能相当

在一些对随机IO性能要求较高的环境下，可以尝试使用ext4，比如数据库，大型图片后台存储等