磁盘上最快的Linux文件系统

对瓦状驱动器有很大的兴趣。这些将数据磁道紧密地排列在一起，以至于如果不破坏下一磁道就无法写入一个磁道。这可能会使容量增加20％左右，但会导致写入放大问题。针对Shingled驱动器进行了优化的文件系统正在进行中，例如，请参见：https : //lwn.net/Articles/591782/

诸如Seagate 8TB存档之类的带碎片的磁盘具有用于随机写入的缓存区域，从而在通用文件系统上提供了不错的性能。在某些常见的工作负载上，磁盘甚至可以非常快，写入速度高达200MB /秒。但是，可以预料的是，如果随机写缓存溢出，则性能可能会受到影响。大概是，某些文件系统通常更擅长避免随机写入，或者在这种驱动器中发现的随机写入模式可能会溢出写入缓存。

与ext4相比，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

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

如果你rsync 从一个SMR驱动器，确保文件系统安装read-only或noatime选项。

否则，SMR驱动器将需要为rsync读取的每个文件编写时间戳，从而导致性能显着下降（从大约80 mb / s降低到此处的3-5 mb / s）和磁头磨损/咔嗒声。

如果您已经运行了性能不佳的rsync作业，则无需停止它，则可以重新挂载源文件系统

sudo mount -o remount,ro  /path/to/source/fs

请耐心等待10到20分钟，直到驱动器完成写出仍保留在其缓冲区中的所有数据后，才能立即看到效果。这个建议是经过尝试和确定的。

当这可能也适用rsync荷兰国际集团到一个SMR驱动器，也就是说，如果文件系统试图更新时间戳记后该文件已被完全写入到磁盘中。连续的工作负载抖动和大量数据不断被重写，导致驱动器磨损。以下内容可能会有所帮助：

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

必须在运行rsync之前完成此操作。其他因素可能会使此选项无关紧要，例如，如果文件系统主要针对SSD进行了优化，则无缓冲FAT / MFT更新，并行化写入等。

dd bs=32M如果仍然要备份完整的文件系统，请尝试使用SMR目标上的文件系统，然后调整其大小（在这种情况下，无需挂载它并运行rsync来传输每个文件）。

实际使用的硬件是Seagate驱动器管理的SMR 8tb消费者驱动器。您的里程可能会因其他硬件而异。