叠瓦磁盘上最快的 Linux 文件系统

Question

人们对叠瓦式驱动器产生了相当大的兴趣。这些将数据轨道靠得很近，以至于您无法在不破坏下一个轨道的情况下写入一个轨道。这可能会增加 20% 左右的容量，但会导致写入放大问题。针对带状疱疹驱动器优化的文件系统正在进行中，例如参见：https : //lwn.net/Articles/591782/

一些叠瓦式磁盘（例如 Seagate 8TB 存档）具有用于随机写入的缓存区域，从而可以在通用文件系统上获得不错的性能。在一些常见的工作负载上，磁盘甚至可以非常快，高达约 200MB/秒的写入。但是，可以预料，如果随机写入缓存溢出，性能可能会受到影响。据推测，某些文件系统通常更擅长避免随机写入，或者可能会溢出此类驱动器中的写入缓存的随机写入模式。

linux 内核中的主流文件系统是否比 ext4更能避免叠瓦磁盘的性能损失？

Answer 1

通过减少随机写入，直观的 C​​opy-on-Write 和 Log 结构化文件系统可能会在叠瓦磁盘上提供更好的性能。基准测试在某种程度上支持这一点，但是，这些性能差异并非特定于叠瓦磁盘。它们也发生在用作控件的未叠盖磁盘上。因此，切换到叠瓦磁盘可能与您选择的文件系统没有太大关系。

nilfs2 文件系统在 SMR 磁盘上提供了相当好的性能。但是，这是因为我分配了整个 8TB 分区，而基准测试只写入了 ~0.5TB，因此 nilfs 清洁器不必运行。当我将分区限制为 200GB 时，nilfs 基准测试甚至没有成功完成。如果您真的将“存档”磁盘用作存档磁盘，在其中将所有数据和快照永久写入磁盘，则 Nilfs2 可能是性能方面的不错选择，因为这样就不必运行 nilfs 清洁器。

我知道ST8000AS0002-1NA17Z我用于测试的 8TB 希捷硬盘有大约 20GB 的缓存区域。我更改了默认的 filebench 文件服务器设置，以便基准设置为 ~125GB，大于未折叠的缓存区域：

set $meanfilesize=1310720
set $nfiles=100000
run 36000

现在为实际数据。ops 的数量衡量“整体”文件服务器性能，而 ms/op 衡量随机追加的延迟，可用作随机写入性能的粗略指南。

$ 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

在这三个文件系统中，将相同 1 TB 磁盘的第二个副本添加到阁楼需要 4.5 小时。基准测试和smartctl信息的原始转储位于：http : //pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR