momo 发表于 2019-5-18 13:50:58

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

在最近几年,Linux社区中有相当多的关于哪个文件系统最适合实现其目标 - 组织文件的发酵。在无休止的讨论中,我们可以读到一个文件系统相对于另一个文件系统所谓的优越性,但是这些语句通常缺少一些客观的数据点来证明这一点。由于一个典型的Linux用户可以从众多非常不同的文件系统中进行选择,我想给你一些数字来比较它们。在本文中,我们将重点介绍这些文件系统的性能:
[*]ext3 ,这是近十年来的“标准”Linux文件系统;
[*]ext4 ,备受期待的ext3接班人;
[*]xfs ,一种最初由Silicon Graphics,Inc。为IRIX操作系统开发的高性能文件系统;
[*]btrfs ,一个新的,下一代文件系统,开发时考虑了可扩展性。
上述文件系统具有完全不同的功能,ext3具有更有限的功能集。但是,这篇文章不是关于功能:如果你需要这样的比较,你可以参考非常完整的维基百科文章本文是关于性能的:我们将看到哪个文件系统执行得最好以及哪个边缘。请记住,不同的使用模式可以支持不同的文件系统,因此我不会假装选择世界上总是更好,更强大的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时,最快的文件系统是什么?不要被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/index.php/linux-a-unix/6-linux-filesystems-benchmarked-ext3-vs-ext4-vs-xfs-vs-btrfs.html?limitstart=0

panrui 发表于 2019-5-18 14:28:52

学习了!

wjq_xp 发表于 2019-5-18 22:25:00

结果呢,用哪个?

oiwww 发表于 2019-5-21 10:41:40

Btrfs用了几年了,要换EXT4?

3008086 发表于 2019-5-21 10:50:13

技术贴必须要收藏。

mengtw 发表于 2019-5-22 09:54:37

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

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

xiyuxixi 发表于 2019-5-22 10:15:35


技术贴必须要收藏。

mosiganyy 发表于 2019-5-22 10:20:53

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

635601535 发表于 2019-7-31 13:32:19

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

dunge 发表于 2019-8-23 23:23:34

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

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

carter2005 发表于 2019-8-24 07:37:41

本帖最后由 carter2005 于 2019-8-24 11:46 编辑

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

jl760102 发表于 2019-9-1 15:19:54

我选了btrfs

xhgx190901 发表于 2019-9-1 17:34:39

学习一下

cuisong_vip 发表于 2020-5-28 17:16:19

结果呢,用哪个?结果呢,用哪个?
页: [1]
查看完整版本: 群晖选择Ext4还是btrfs 请看linux文件系统基准测试