当前位置:   article > 正文

最快的linux文件系统,磁盘上最快的Linux文件系统

linux 那个文件系统读写速度块

直观地写时复制和日志结构化文件系统可能会通过减少减少的随机写入来在带碎片的磁盘上提供更好的性能。基准测试在某种程度上支持了这一点,但是,这些性能差异并不特定于带碎片的磁盘。它们也出现在用作控件的非平铺磁盘上。因此,切换到带碎片的磁盘可能与您选择的文件系统没有太大关系。

nilfs2文件系统在SMR磁盘上提供了相当不错的性能。但是,这是因为我分配了整个8TB分区,而基准测试仅写入了约0.5TB,因此Nilfs Cleaner不必运行。当我将分区限制为200GB时,nilfs基准测试甚至没有成功完成。如果您确实使用“存档”磁盘作为存档磁盘,并且将所有数据和快照永久写入磁盘,那么Nilfs2可能是性能的明智选择,因为这样就不必运行Nilfs Cleaner。

我了解到,ST8000AS0002-1NA17Z我用于测试的8TB希捷硬盘具有约20GB的缓存区域。我更改了默认的filebench文件服务器设置,以使基准设置为〜125GB,大于未平铺的缓存区域:

set $meanfilesize=1310720

set $nfiles=100000

run 36000

现在获取实际数据。操作数衡量“整体”文件服务器的性能,而毫秒数/操作数衡量随机追加的延迟,并且可以用作随机写入性能的粗略指南。

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' | column -t

SMR8TB.nilfs appendfilerand1 292176ops 8ops/s 0.1mb/s 1575.7ms/op 95884us/op-cpu [0ms - 7169ms]

SMR.btrfs appendfilerand1 214418ops 6ops/s 0.0mb/s 1780.7ms/op 47361us/op-cpu [0ms-20242ms]

SMR.ext4 appendfilerand1 172668ops 5ops/s 0.0mb/s 1328.6ms/op 25836us/op-cpu [0ms-31373ms]

SMR.xfs appendfilerand1 149254ops 4ops/s 0.0mb/s 669.9ms/op 19367us/op-cpu [0ms-19994ms]

Toshiba.btrfs appendfilerand1 634755ops 18ops/s 0.1mb/s 652.5ms/op 62758us/op-cpu [0ms-5219ms]

Toshiba.ext4 appendfilerand1 466044ops 13ops/s 0.1mb/s 270.6ms/op 23689us/op-cpu [0ms-4239ms]

Toshiba.xfs appendfilerand1 368670ops 10ops/s 0.1mb/s 195.6ms/op 19084us/op-cpu [0ms-2994ms]

由于希捷的速度是5980RPM,因此人们可能会天真地希望东芝的速度提高20%。这些基准测试表明它的速度大约提高了3倍(200%),因此这些基准测试受到了性能上的限制。我们看到,带状疱疹(SMR)磁盘仍无法与非带状疱疹(PMR)磁盘上的ext4性能相提并论。最好的性能是带有8TB分区的nilfs2(因此清洁器不需要运行),但即使这样,它也比带有ext4的东芝要慢得多。

为了使上述基准更加清晰,可能相对于每个磁盘上ext4的性能将其标准化:

ops randappend

SMR.btrfs: 1.24 0.74

SMR.ext4: 1 1

SMR.xfs: 0.86 1.98

Toshiba.btrfs: 1.36 0.41

Toshiba.ext4: 1 1

Toshiba.xfs: 0.79 1.38

我们看到,在SMR磁盘上,btrfs在ext4上具有总体操作的大部分优势,但是对随机追加的惩罚却不如比率高。这可能会导致迁移到SMR磁盘上的btrfs。另一方面,如果您需要低延迟的随机附加,则该基准测试建议您使用xfs,尤其是在SMR上。我们看到,尽管SMR / PMR可能会影响您对文件系统的选择,但考虑要优化的工作负载似乎更为重要。

我还运行了一个基于阁楼的基准测试。阁楼运行的持续时间(在8TB SMR全磁盘分区上)为:

ext4: 1 days 1 hours 19 minutes 54.69 seconds

btrfs: 1 days 40 minutes 8.93 seconds

nilfs: 22 hours 12 minutes 26.89 seconds

在每种情况下,阁楼存储库都有以下统计信息:

Original size Compressed size Deduplicated size

This archive: 1.00 TB 639.69 GB 515.84 GB

All archives: 901.92 GB 639.69 GB 515.84 GB

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/盐析白兔/article/detail/797168
推荐阅读
相关标签
  

闽ICP备14008679号