BTRFS - Performance-阿里云开发者社区

转载：https://blog.csdn.net/PANGHAIFEI/article/details/100727006

没有商定的测试文件系统性能的标准。虽然有NFS和CIFS的行业基准，他们仅仅覆盖现场看到的一小部分的工作量。在一天结束时，对用户来说最重要的是他特殊应用的性能。检查哪个文件系统时最好的匹配一个特殊的使用例子的唯一现实的方法时去尝试几种文件系统，看看哪一种工作的最好。

因为我们不能覆盖所有的用例，我们选择了一种常见的基准，去展示BTRFS与同期的比较。在写的时候，主要Linux文件系统，除了BTRFS，是XFS,EXT4。这些很显然是很成熟的系统，并且我们不希望去更好的执行数量级（啥意思这是）。我们的贡献是支持新功能的文件系统，比如快照和数据校验，在最大负载之下提供合理的性能。

两种存储配置被选择：一个硬盘和一个SSD。

（一）硬盘

所有在单个插槽上运行的硬盘测试3.2 Ghz四核x86处理器，单个SATA驱动器上具有8 Gb内存，带有6gb / s链路。

第一个测试时一个Linux kernel make，从干净的源文件树开始。收集了一个块跟踪，从命令 make -j8 开始。这个启动了8个并行线程编译和链接gcc。表1比较了在三种文件系统之间的吞吐量， seek count and IOps。EXT4的吞吐量略高于BTRFS和XFS，平均吞吐量不到两倍。所有文件系统保持每秒大约相同的搜索量，BTRFS的平均搜索更少一些。BTRFS运行初期的飙升很大可能是因为处理在不同块组之间反弹的初始写入时写入位。一旦额外的块组被分配去处理元数据加载，一切顺利。每秒的IO操作有点紧密，但是EXT4再次获胜。编译时间都在几秒之内。内核编译测试往往有点元数据密集，对于一个拥有强负载的应用这是一个很好的基准。整体情况是文件系统通常都是平价的。

表1：内核编译，所有文件系统展示类似的性能

FFSB测试尝试去模仿一个邮件服务器。它在1000目录下创建了500000文件，尺寸从1KB到1MB不等，加权到32KB或者更小不等。一旦它创建文件，他消费300秒去创建，删除或者读取整个文件，都是以4KB的块大小尺寸。读取的权重高于创建，创建高于删除以尝试表示邮件服务器的工作方式。测试可以被修改去使用任意数量的线程，更简单地，我们使用一个线程。FFSB测量吞吐量和每秒的交易量。看表2

表2：在FFSB邮件服务运行期间的吞吐量。XFS使用最少的带宽，EXT4使用最多，BTRFS处于中间。

表3：FFSB中的每秒交易量。BTRFS展示了相对好的性能。

这个工作量有利于EXT4，BTRFS略微落后，XFS性能只有BTRFS的一半.

最终测试处理写性能。Tiobench以一个特定数量的线程写一个给定的尺寸到文件中。我们使用一个2000MB的文件并且运行1，2，4，8和16个线程。两个测试显示总体上BTRFS运行最快。在随机情况下主导了其他两个文件系统。随机情况下有可能BTRFS更好，因为它写任何地方，并且因为我们使用范围锁去写而不是全局的inode锁，这样使得并行操作会更快。性能随着额外的线程有些下降，因为共享inode 锁的争夺。

表4：TIO benchmark, sequential

表5：TIO benchmark,random

这仅仅是三个测试并且绝不能用各种方式去使用文件系统。幸运的是，他们代表了大多数文件系统的使用方式。在所有这些例子中，BTRFS与成熟的同类产品差不多。

（二）Flash disk

Flash disks 正在变得普及，在许多现代笔记本电脑中正在代替传统的硬盘。手机和嵌入式设备运行普通的Linux也会使用flash disks。这个对优化BTRFS对SSDs有一个持续性的激励。我们描述了一些工作；代码是Linux Kernel 3.4的一部分。硬件使用一个FusionIO 设备。

表6描绘了Linux 3.3内核的性能，用BTRFS创建32百万的空文件。表是由Seekwatcher生成的，一个可视化硬盘移动的工具。在顶部表X轴是时间，Y轴是硬盘磁头的定位，读取被标记为蓝色，写被标记为绿色。底部图表跟踪吞吐量。文件系统开始是空的，填写空文件作为测试进度。从图中出现的模式是一个连续的进展，在最后写新文件。文件元数据是批量的，并且在检查点的期间是顺序写的。检查点每三十秒会发生一次。它们导致许多的随机读，表现为散列的蓝点。读取需要访问空闲空间分配树，一个太大不适合在内存中的结构。额外的磁盘检索大大的减慢了系统的速度，也可以在吞吐量图表中看到。写进度不是线性的原因是检查点，额外的写一些新的数据，也会释放块；这些随后会被重复使用。

表6：内核3.3的性能。文件创建率是不稳定的。吞吐量是一系列的峰值和谷值。

为了提高性能，读取的数量不得不减少。核心问题证明是Linux 虚拟内存系统被使用的方式。VM假设分配页将被使用一会。BTRFS，使用许多临时的页因为写时复制的性质，数据可以在磁盘上移动。这个不匹配导致VM保持需要过期的页，减少缓存的效用。反过来，引起额外的页在空闲空间分配树中, 因为缓存的压力该分配树被抛出缓存中。在可用空间分配树中引起了额外的分页，由于高速缓存压力，该分页树被抛出缓存。修复是让BTRFS更加努力地从已经变为无效的VM页面中丢弃.表7展示性能提高的结果。读取的数量减少了，他们更加集中于检查点的间隔。吞吐量稳定于大约125MB/sec，文件创建率是每秒150000个。