☰

ZFS zpool 的 ashift 错误。这有多严重？

tag-icon • tag-icon hard-drive raid zfs
ZFS zpool 的 ashift 错误。这有多严重？

我有一个 3x1TB ZFS (ZoL) RAIDZ1。一个驱动器出现故障。我将用一个 4TB 磁盘替换它。

$ sudo zpool replace pool <old guid> /dev/disk/by-id/<new id>

cannot replace <old guid> with /dev/disk/by-id/<new id>: 
new device has a different optimal sector size; 
use the option '-o ashift=N' to override the optimal size

$ zdb -C | grep ashift
            ashift: 9

$ sudo zpool replace pool <old guid> /dev/disk/by-id/<new id> -o ashift=9

这有效。阵列现在正在重新同步。但是，说实话，我不明白这个设置的影响。我只想尽快更换故障磁盘，并在不久的将来将其他 1TB 磁盘替换为 4TB 磁盘。但事后看来，对齐移位为 2^9 的性能被描述为可怕的。

我知道这个设置是不可变的。一旦我更换了另外两个磁盘，我就无法将值更改ashift为 2^12，如果我理解正确的话，这是 4TB 磁盘的推荐值。

我是不是搬起石头砸自己的脚？如何才能最好地处理？我是否可以禁用 autoexpand新阵列并创建新卷，然后ashift=12将旧卷复制到同一驱动器上的新卷？这样做可行吗？值得推荐吗？

答案1

选择太小的ashift值实际上会导致磁盘在执行写入时在内部执行读取-修改-写入。您是否会注意到性能下降取决于您的使用模式 - 您是否执行大量同步写入并且需要非常高的性能？如果答案是肯定的，您会注意到差异，但如果没有，您可能不会。异步写入不会受到此影响，因为 ZFS 将这些写入批量处理为大型多块更新，这意味着不会有大量子块写入（因为只有大型连续写入中的第一个和最后一个块可以是子块）。

切换到 4KiB 块的主要缺点是压缩效果不佳，因为它只能将压缩块四舍五入到最接近的 4KiB，而不是最接近的 512B。如果这对你来说比顶级写入性能更重要，那么也许可以保持原样。

如果写入性能确实很重要，则应该重建池。我认为最简单的方法是对按所需方式配置的新池执行zfs send/ 。zfs receive

关于如何避免一次性购买新池的所有硬件并进行清理send/的具体建议receive：由于您已经有使用ashift9 写入的数据，因此无法将使用ashift12 的磁盘添加到池中（ZFS 无法寻址在 4KiB 对齐的磁盘上对齐 512B 的块；这ashift是顶级 vdev 上的设置，而不是磁盘上的设置）— 因此您看到了警告。可能可以在新驱动器的后半部分创建一个新池并将第一个池中的所有数据复制到其中，但其冗余度与原始池不同，因为您无法从一个磁盘的一个分区构建 RAIDZ1。也许您可以复制到没有冗余的第二个池，然后将原始池中的磁盘 / 分区重新配置为正确的ashift/ 冗余度，然后将所有数据复制回来。

相关内容