群晖选择Ext4还是btrfs 请看linux文件系统基准测试

在最近几年，Linux社区中有相当多的关于哪个文件系统最适合实现其目标 - 组织文件的发酵。在无休止的讨论中，我们可以读到一个文件系统相对于另一个文件系统所谓的优越性，但是这些语句通常缺少一些客观的数据点来证明这一点。

由于一个典型的Linux用户可以从众多非常不同的文件系统中进行选择，我想给你一些数字来比较它们。在本文中，我们将重点介绍这些文件系统的性能：

• ext3 ，这是近十年来的“标准”Linux文件系统;
• ext4 ，备受期待的ext3接班人;
• xfs ，一种最初由Silicon Graphics，Inc。为IRIX操作系统开发的高性能文件系统;
• btrfs ，一个新的，下一代文件系统，开发时考虑了可扩展性。
  
  

上述文件系统具有完全不同的功能，ext3具有更有限的功能集。但是，这篇文章不是关于功能：如果你需要这样的比较，你可以参考非常完整的维基百科文章[1]

本文是关于性能的：我们将看到哪个文件系统执行得最好以及哪个边缘。请记住，不同的使用模式可以支持不同的文件系统，因此我不会假装选择世界上总是更好，更强大的FS。我只想给你一些以各种使用模式收集的数字，以便我可以帮助你选择正确的文件系统来完成一些常见的工作。

还请考虑内核版本之间的FS性能差异很大。例如，EXT4和BTRFS都有一些速度提升和最新内核版本之间的一些严重回归。您可以在Phoronix的网站和其他Web源上阅读有关这些改进/回归的一些非常有趣的测试。

那么，让我们继续......

Bonnie ++：顺序I / O带宽

bonnie ++套件使我们能够做一些非常有趣的测量。第一张图显示了一次使用一个字符的顺序I / O带宽和CPU使用率：

正如您所看到的，绝对值非常低（最大约1600 KB /秒），但这是预期的：硬盘是块设备，因此在这种测试中效率非常低。而且，CPU一次只发出一个字符非常繁忙。这意味着此测试实际上测量的是文件系统效率而不是原始I / O带宽。你可以看到BTRFS在这里变得越来越差，因为它只能传输~200 KB /秒，CPU负载大约为100％。相比之下，EXT3和EXT4在输入测试中要快得多，但在输出测试中只有稍微好一些。XFS在这里看起来最平衡：它的输入速度仅略高于EXT3 / 4速率，而在输出测试中得分更高2倍。

但是，硬盘是块设备：这意味着块I / O测试更有意义：

在这里我们可以看到绝对值非常匹配，具体取决于文件系统结构以外的硬盘性能。但是，CPU负载数据表明并非所有文件系统都同样有效：XFS在这里看起来最好，其次是EXT4，然后是EXT3，最后是BTRFS。虽然差异不是很大（我们说的是一些％点），但确实很有趣。

现在，我们来看看直接数据传输（例如：没有任何OS / FS缓存方案）：

该图表似乎表明，对于需要直接访问文件系统的应用程序，绕过OS / FS缓存（例如：视频录制，某些虚拟机软件，ecc。），EXT3 / 4是最佳选择，其次是BTRFS，最后地方，XFS。

第一轮测试证明我们在这个领域没有灵丹妙药：我们没有一个总是更好的文件系统。这一切都归结为您的使用模式。但是，看起来BTRFS在配置文件方面可能会有点问题。

但是让我们来看看其他一些bonnie ++测试......

Bonnie ++：随机搜索和文件处理

下图显示了每秒随机搜索次数和相应的CPU负载：

BTRFS的结果非常令人失望：不仅它的得分低于20次/秒，而且还导致350％的CPU负载！这很奇怪，因为最大CPU负载只能达到200％（请记住这是双核机器）。可以是bonnie ++测量误差吗？是的，但我不确定，因为EXT3，EXT4和XFS似乎得分。请注意，EXT3在这里是最快的：这是一个重要的胜利，因为随机性能与大量应用程序相关。相比之下，非常低的BTRFS分数可能与非常复杂的元数据处理有关。

创建和删除大量文件时这些文件系统如何堆叠？

哇！到目前为止，BTRFS是最慢的，我们无法正确读取其他结果。让我们检查没有BTRFS得分的相同数据：

现在我们可以看到EXT4是更快，更高效的文件系统，其次是XFS，最后是EXT3。这个文件创建/删除测试证实了我对BTRFS文件系统过于复杂的元数据处理的猜测。另一方面，具有延迟分配能力的FS（EXT4和XFS）比旧的EXT3快。

Sysbench：读/写速度

Sysbench fileio测试对于测量bonnie ++的不同使用模式下的I / O速度非常有用。

例如，sysbench fileio test默认情况下每100次写入请求发出一次fsync（），但是让我们选择一种更积极的，一次写入/一次fsync（）使用模式。第一种情况尝试模仿正常的磁盘活动（例如：使用操作系统定期调用的fsync（）），而后者使我们能够镜像一些数据库使用模式（例如：每次写入必须同步到磁盘）。

第一个图表测量顺序读/写速度，包括100个写入/一个fsync（）和一个写入/一个fsync（）模式：

如您所见，使用默认设置（100次写入/一次fsync（）），所有竞争者的行为都相似。但是，通过发出更多fsync（），我们发现EXT3比其他更快（它的得分几乎比XFS高2倍）。我们也看到了一个非常奇怪的BTRFS行为：读取速度应该不受fsync（）的影响（这个是一个与写操作相关的操作），它在这个测试中失去了相当多的速度。为什么？由于read + fsync（）测试是在write + fsync（）之后执行的，可能与写入测试在磁盘上组织数据的方式有关：通过在每次写入后发出fsync（），FS可以减少有机会在磁盘上优化组织数据。

现在，让我们看看随机读/写速度：

我们现在看到一个非常复杂的包。EXT4似乎是最受惩罚的文件系统，而XFS似乎是最快的。

然而，23 MB /秒的真正随机读取速度远远超过普通机械硬盘的能力。例如，考虑大约10毫秒的访问时间：这给我们大约100个搜索/秒并且将该数字乘以sysbench默认块大小（16 KB），我们最多大约1600 KB /秒用于读取真正的随机数据a一次一个块。即使考虑到默认情况下，sysbench仅使用2 GB的磁盘空间，因此访问时间有可能在4 ms左右下降，XFS和BTRFS分数超过了理论上可达到的最大性能。我不是说这是一件坏事：毕竟，我已经多次检查了结果，我可以保证这两个FS在这个测试中真的比EXT3 / 4快。然而，

还要注意，当我第一次运行write + fsync（）测试时，XFS和BTRFS都显示出更高的读取分数：在这种情况下，似乎在不发出那么多fsync（）时进行的优化会适得其反。也许我找到了一个角落案例，其中XFS和BTRFS的延迟分配器并不那么聪明; 每次写入请求发出一个fsync（），我们实际上强制FS忘记延迟分配，迫使它立即写入数据。

谈到写入速度，我们发现最快的FS到目前为止是EXT3。XFS处于非常遥远的第二位，其次是其他两个文件系统。如此低的（伪）随机写入速度会严重影响作为数据库，高容量日志记录程序和虚拟机系统的写密集型应用程序。

Sysbench：PostgreSQL性能

第一个PostgreSQL基准测试准备（填充）数据库所需的时间。它写了一个100000记录长度的表：

最后，我们看到一个测试是BTRFS是最好的！虽然它的速度几乎与EXT3相当，但BTRFS可以拥有超低的CPU使用率。另一方面，虽然EXT4和XFS具有相同的超低CPU利用率，但它们慢了10倍。怎么可能？也许我们遇到一个EXT4 / XFS回归，因为有点类似的Phoronix的SQLite和Postmark测试似乎表明在最近的内核中EXT4的这种工作负载严重减速。

现在，让我们看看sysbench的简单测试结果：

这是一个100000请求，只读测试。由于我们没有写活动，我没想到结果之间会有很大差异：我们发现所有文件系统在这里或多或少都是等价的。

更复杂的读写事务测试可以画出不同的画面吗？

是的，它可以：BTRFS现在非常慢，得分少于EXT4和XFS的1/4。EXT3是明显的赢家：它的EXT4 / XFS性能是这里的4倍（所以它比BTRFS快16倍！）。

这个测试显示，对于数据库系统，你应该真正使用EXT3，至少在未来的内核中解决EXT4回归之前。

现实场景：解开和猫

现在是时候进行更多的行人测试了。例如，解开vanilla Linux内核2.6.36时，最快的文件系统是什么？[2]

不要被XFS低CPU使用率所欺骗，因为它的FS越来越慢。考虑到所有因素，最好的FS似乎是EXT4：它的速度与EXT3和BTRFS相当，同时使用更少的CPU时间。但是，除了XFS之外，所有FS都执行大致相同的操作。

但是，此测试肯定会受到缓存和延迟分配等功能的影响。发出最终同步时会发生什么？

我们可以看到XFS继续是较慢的FS，EXT3的执行速度也比EXT4和BTRFS慢，后者是速度最快的FS。

如何捕获所有提取的文件？

在这个读取绑定测试中，EXT3和EXT4显示效果不佳。相比之下，XFS尤其是BTRFS更快。但是，后者具有相当高的CPU负载，因此XFS在这里是首选。注意BTRFS的系统CPU时间稍微高一点：它有助于证明这个文件系统有一个非常复杂的元数据方案。

碎片化：Linux内核解压缩

当单个文件被分成多个不连续的部分称为片段时，我们谈论碎片。与标准机械驱动一样，每个磁头寻道非常昂贵（在大多数产品上为5-15 ms，而入门级过程的CPU时钟周期以ns为单位测量，大约低6个数量级）碎片是任何人的第一个敌人文件系统。一个严重的，随机碎片的文件系统将比一个低碎片的文件系统慢得多。

通过使用以下两种策略中的至少一种可以解决此问题：

• 在常规基础上运行碎片整理程序（一种专门用于重新组织磁盘上文件的软件，以便在更大的单个连续片段中重新组织各种文件片段）;
• 在文件系统中直接实现一些非分段逻辑（这样，对于每次写入，文件系统都会尝试使用连续的磁盘空间）。
  
  

第一个解决方案肯定非常不舒服（因为我们必须处理定期碎片整理），但它可以实现一些复杂的逻辑，几乎完全消除碎片。第二种可能性更加透明（我们没有做任何特别的事情），但可能更容易出现碎片。

Windows系统选择第一种方法：从Win2000开始，Microsoft包含一个用于NTFS卷的在线碎片整理程序。

Linux文件系统历来选择第二条路径：所有基准测试文件系统都集成了一些非分段逻辑，并非所有文件系统都有一个在线甚至是离线碎片整理程序。XFS是目前唯一拥有稳定的在线碎片整理程序的人（EXT4有一个名为e4freefrag的beta在线碎片整理程序，但此时并未包含在任何发行版中）。

那么，这些文件系统在碎片方面的表现如何呢？让我们从一个简单的常见任务开始：解开Linux内核。此操作按顺序创建超过32000个文件：

正如您所看到的，在这个简单的操作中，最近的文件系统是完美的，每个文件平均有一个片段。老化的EXT3文件系统（唯一没有延迟分配功能的文件系统）非常糟糕，但毕竟它并不是那么糟糕。

碎片：Sysbench写测试

从碎片的角度来看，先前的解压测试非常简单：提取的文件非常小并且是按顺序创建的。但是这些文件系统如何通过更复杂的顺序测试来表现？让我们看一下sysbench顺序写入测试，创建128个文件，每个长16 MB（总共2 GB）：

嗯...似乎没有延迟分配（记住一个写/一个fsync（）范例有效地禁用它）BTRFS有一些非常严重的碎片问题。这也解释了之前测试中发现的低读取速度。查看没有BTRFS数据点的同一图表：

我们可以看到EXT3再次比EXT4和XFS更差。当与延迟分配一起使用时，这两个文件系统可以非常接近完美的一个文件/一个片段比率。当我们强制一个写/一个fsync（）模式（有效地禁用延迟分配）时，碎片级别增加，但它仍然小于EXT3的2倍。

目前，我们将自己集中在顺序写入测试上。在这种测试中，我们看到了EXT4和XFS的非常好的结果，在某一点上我们可以问自己是否值得使用（最终可用的）在线或离线碎片整理程序。根据定义，随机写入测试如何更容易出现碎片？此测试使用相同的128,16 MB长文件，但重写10000个16 KB长请求（总计超过156 MB的随机写入数据）：

随机写入测试向我们表明，在繁重的环境中，所有这些Linux文件系统都可能变得非常分散。正如预期的那样，在这种情况下，延迟分配器没有帮助（它不能将这些随机写入合并到一个片段中的不同位置）。EXT4似乎比XFS和EXT3领先一点，而BTRFS更糟糕。但是，考虑到XFS有一个可用的在线碎片整理程序，我认为它在此测试中也具有优势。

结论

如果你耐心阅读这篇长篇文章，我相信如果我说文件系统基准测试不是一件容易的事，你就同意我的看法。这里有许多变量在起作用; 记住你只有最伟大的：

• 不同的内核发布会产生截然不同的结果;
• 不同的使用模式有利于不同的文件系
• 不同的文件系统选项可能会对其在特定测试中的性能产生很大（正面或负面）影响。
  
  

那么，考虑到这些警告，有可能得出一些有意义的结论并给你一些有根据的提示吗？幸运的是，是的。

让我们从最明显的开始：最好的平衡文件系统似乎是成熟的，几乎老化的EXT3。 更新：EXT3是错误的基准与屏障关闭。请阅读本页末尾的注释。这是很自然的，因为它在很长一段时间内获得了大多数累积改进。它具有非常好的顺序和随机写入速度以及合理的读取速度，这些因素对于几个不同的任务至关重要。例如，如果您计划运行数据库服务器，则几乎不得不使用EXT3，因为所有其他文件系统似乎在同步随机写入速度方面存在很大问题。此外，如果您在工作站上使用EXT3，则不会出错，因为它在大量不同的工作中表现相当不错。最后，EXT3比其他FS更稳定，因为它的大部分bug现在已经解决了。

然而，这并不意味着EXT3是完美的FS：首先，它缺乏延迟分配和在线压缩等一些重要功能。它也缺乏本机快照功能，但您可以使用LVM来克服这个问题。它比EXT4和XFS更容易碎片，并且在创建/删除大量文件时速度很慢，表示不太好的元数据处理。而且，它比EXT4和XFS使用更多的CPU周期，但是对于今天的CPU我不认为这是一个很大的问题。如果你能忍受这些小故障，EXT3是适合你的文件系统。

它的继任者EXT4文件系统怎么样？这是一个重要的进化步骤，欢迎使用延迟分配，范围和更有效的元数据处理。

然而，它的表现并不是那么出色：特别是在同步写入和数据库测试中，它大大落后于EXT3。 更新：EXT3显示更快的结果，因为它以写屏障关闭为基准。请阅读本页末尾的注释。此外，由于它是一个较年轻的文件系统，它经常被补丁触及，在纠正问题的同时，可能导致速度回归。虽然您可以在工作站上试用它，但我建议您让它慢慢成熟，而不是立即在服务器上使用它。特别是如果您计划使用绕过OS / FS缓存并直接在磁盘上写入的应用程序（视频录制，某些虚拟机，ecc。）除非您至少使用2.6.36内核版本，否则不要使用它，因为async I / O层在以前的内核上存在严重错误。您可以在https://bugzilla.kernel.org/show_bug.cgi?id=16165上阅读更多内容

说到XFS，我可以说它是一个非常好的FS，具有很高的读取速度，良好的元数据处理能力和非常好的可扩展性。

然而，虽然它看起来总体上比EXT4好，但它与后者共享一些严重的问题：慢的随机写入速度和相同的异步I / O层错误（应该在2.6.36内核上纠正）。这意味着我不鼓励在数据库服务器上使用它（出于性能原因）和托管虚拟机的服务器（用于慢速随机写入和异步I / O错误）。但是，XFS应该适用于普通工作站。

BTRFS是一个新的下一代文件系统，虽然从功能的角度来看它看起来非常好（它具有在线压缩和本机快照功能！）但它太慢而且有太多的“尖峰边缘”可用于除了一台试验机。我相信将来这个文件系统会增长得很好，但我们还没有考虑经常使用它。

更新：为另一个基准测试准备系统，我注意到，与Fedora 14文档中的内容相反（http://docs.fedoraproject.org/en-US/Fedora/14/html-single/Storage_Administration_Guide/index.html #writebarrieronoff），写的障碍没有在EXT3文件系统上默认启用，而EXT4，XFS和BTRFS默认情况下正确启用了障碍。写入障碍是一种机制，可以确保在fsync（）之后，所有数据都真正存储在磁盘盘片上。如果没有障碍，您可能会将某些fsynched数据真正存储到磁盘盘片中，但它们会暂时存储在易失性磁盘缓存（DRAM）中。因此，虽然EXT3在某些基准测试中速度非常快，但在某些情况下（例如：突然断电）也可能更容易导致数据丢失。在检查我的结果时请记住这一点。我很遗憾只注意到这件事，但在这种情况下，Fedora文档确实具有误导性......

网上来源：http://www.ilsistemista.net/inde ... s.html?limitstart=0

学习了！

结果呢，用哪个？

Btrfs用了几年了，要换EXT4？

技术贴必须要收藏。

wjq_xp 发表于 2019-5-18 22:25
结果呢，用哪个？

普通用户其实不用纠结这个，，，想用快照brtfs，想与win等快速互通则用ext

技术贴必须要收藏。

嗯，文章很好，不过应该是几年前的测试了，楼主有能找到最新的对比的话就完美了，谢谢楼主

群晖的最新系统已经不支持ext4了  如果使用ext4格式的老机器升级到最新 会直接认不到存储空间 此时即使降级到支持ext4的版本也会认不到存储空间  这点要注意

mengtw 发表于 2019-5-22 09:54
普通用户其实不用纠结这个，，，想用快照brtfs，想与win等快速互通则用ext

精辟，还有群晖上虚机必须bfts

2010年的测试结果了，对于发展迅速的计算机行业而言，基本毫无价值，btrfs的性能对nas来说绰绰有余（千兆确实已经是瓶颈了），更别提备份，虚拟机等应用需要btrfs的特性，在群晖上根本没的选的。

我选了btrfs

学习一下

结果呢，用哪个？结果呢，用哪个？