BTRFS对随机读/写操作的ext4性能

我一直在使用BTRFS文件系统损坏刻录后的过去四年左右的一个非常保守的文件系统选择。

但是,我最近一直在使用许多小文件,以使用静态网站生成器构建此博客。性能并不是很大的,我也发现需要录制文件创建时间,而不是由XFS本地支持的东西。

我的硬件设置由两个旧的旋转软件组成,镜像为我的主目录镜像4 Terabyte硬盘驱动器。我用这些驱动器作为背衬驱动器三星960 EVO NVME固态驱动器作为LVM缓存驱动器的性能。

几个月前,我在几个月前停止使用LVM缓存盘,因为我想要启用全驱动器加密,并且它也阻止了我的系统休眠;问题lvm缓存与bcache共享。无论如何,我被认为是尝试的bcache,但幸运的是,在人们在GCC 9和Linux 5上用BCache发出推动驱动损坏,就幸运的是。

经过仔细审查,我决定缩小我的主目录并使用LUKS加密BTRFS文件系统移动到NVME。我在过去的情况下,我对这个文件系统有不好的经历,但在过去的四年里,肯定发生了一些事情,对吧?

我决定使它成为获得更多现代文件系统的兴趣。我要将很多文件移动到一个单独的驱动器,但清理您的主目录永远不会伤害任何人(假设您正确备份)。

从驻留在硬盘驱动器上的旧主目录中复制文件时,我看到了差的传输速度。在理论上,NVME驱动器在理想条件下理论上是1,28个Gib / s随机写入,但写速度在约30-45 mib / s左右的瓶颈是瓶颈。这些结果非常强大。

在转移并设置后,我还指出,我的静态网站生成器的预期绩效收益低于预期。这两种工作负载都涉及大量随机文件访问和写入。

ext4文件系统是我的第二选择文件系统。我重新启动并重复了BTRF的测试了十几次以获得一些性能指标,并决定在Ext4上重新格式化和重复我的测试。这次围绕旧硬盘驱动器的读取速度在90-105 MIB / s大约90-105 mib / s左右,这是我所期望的一切。随着我的静态网站发电机的绩效收益围绕性能增长也更为显着。

硬件 SATA HDD. NVME SSD.
文件系统 XFS. Btrfs. Ext4.
NANOC编译 89秒 78秒 37秒
NANOC检查 305秒 260秒 196年

SATA驱动器上的XFS不是一个公平的直接比较,但它是在我决定做点什么之前表现的表现的参考。

静态网站生成器需要在编译期间读取8200个文件的文件系统元数据。鉴于这种数据的性质,我们可以假设这些大多是随机读取的。这些数字从六次干运行收集,没有更改的文件,因此没有写入。与BTRF的编译时间减少12,3%是一个很好的改进,但舞曲与在同一硬件上使用ext4看到的58,4%看到的58,4%的减少相比。

检查任务涉及读取大约2000个小文件的全部内容,并在它们上执行一些处理器密集型任务。检查任务随着BTRF的增加14.6%,ext4与35,7%提高了35,7%。

此时,编译时间和检查时间都是由我的CPU瓶颈的。Nanoc的铅开发商Denis Defreyne目前在并行编译接受CPU瓶颈。我希望这些任务应该更快地完成一旦完成,但我怀疑如果我留在我的旧硬件,我不会看到这一切的好处。

好的,这篇文章中的数字告诉我们什么?显然,它确认了更快的I / O的硬件确实更快。但是,它还证实了调查结果Phoronix的Linux 5.0文件系统性能基准对于随机的随机和写入真实的工作量而不是使用合成基准。

作为一个很好而意想不到的奖金,Linux之前需要的时间提示我在启动期间为我的驱动器解密密码丢弃从大约45-ish秒到大约6秒。