人们对瓦片式驱动器非常感兴趣。这些驱动器将数据轨道放在非常近的位置，以至于您无法在不破坏下一个轨道的情况下写入一个轨道。这可能会将容量提高 20% 左右，但会导致写入放大问题。目前正在对针对瓦片式驱动器进行优化的文件系统进行研究，例如，请参阅：https://lwn.net/Articles/591782/
一些叠瓦式磁盘（例如 Seagate 8TB 存档）具有用于随机写入的缓存区域，可在通用文件系统上提供不错的性能。在某些常见工作负载下，磁盘甚至可以非常快，写入速度高达 200MB/秒左右。但是，可以预料的是，如果随机写入缓存溢出，性能可能会受到影响。据推测，某些文件系统在避免随机写入方面做得更好，或者避免随机写入模式可能会溢出此类驱动器中的写入缓存。
是Linux内核中的主流文件系统更好地避免叠瓦磁盘的性能损失比 ext4？
答案1
直观地看，写时复制和日志结构文件系统可能通过减少随机写入在瓦片磁盘上提供更好的性能。基准测试在某种程度上支持了这一点，但是，这些性能差异并不特定于瓦片磁盘。它们也发生在用作对照的非瓦片磁盘上。因此，切换到瓦片磁盘可能与您选择的文件系统没有太大关系。
nilfs2 文件系统在 SMR 磁盘上的性能相当不错。但是，这是因为我分配了整个 8TB 分区，而基准测试仅写入约 0.5TB，因此 nilfs 清理程序无需运行。当我将分区限制为 200GB 时，nilfs 基准测试甚至无法成功完成。如果您真的将“存档”磁盘用作存档磁盘，将所有数据和快照永久保存到磁盘中，那么 Nilfs2 可能是一个性能方面的不错选择，因为这样 nilfs 清理程序就无需运行。
我了解ST8000AS0002-1NA17Z我用于测试的 8TB 希捷硬盘有一个~20GB缓存区域。我更改了默认的 filebench 文件服务器设置，以便基准设置约为 125GB，大于非瓦片缓存区域：
set $meanfilesize=1310720
set $nfiles=100000
run 36000
现在来看看实际数据。操作数衡量“整体”文件服务器性能，而 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]
由于 Seagate 的转速为 5980RPM，人们可能会天真地认为东芝的速度会快 20%。这些基准测试显示它的速度大约快了 3 倍（200%），因此这些基准测试正在达到瓦片性能损失。我们看到瓦片 (SMR) 磁盘仍然无法与 ext4 在非瓦片 (PMR) 磁盘上的性能相匹配。最佳性能是使用 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
在三个文件系统上，向 attic 添加同一 1 TB 磁盘的第二个副本需要 4.5 小时。基准测试和smartctl信息的原始转储位于：
http://pastebin.com/tYK2Uj76
https://github.com/gmatht/joshell/tree/master/benchmarks/SMR
答案2
如果你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 之前完成；其他因素可能会使此选项变得无关紧要，例如无缓冲的 FAT/MFT 更新、如果文件系统主要针对 SSD 进行优化则并行写入等。
如果您无论如何都想备份完整的文件系统，请尝试使用dd bs=32M然后调整 SMR 目标上的文件系统的大小（在这种情况下，无需安装它并运行 rsync 来传输每个文件）。
实际使用的硬件是 Seagate 硬盘管理的 SMR 8TB 消费级硬盘。其他硬件可能与您的里程数不同。