ZFS zpool 错误 ashift。这有多糟糕？

Question

我有一个 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，并将旧卷复制到同一驱动器上的新卷吗？这是可能的和值得推荐的吗？

Answer 1

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

\n\n

切换到 4KiB 块的主要缺点是压缩也不起作用，因为它只能将压缩块舍入到最接近的 4KiB 而不是最接近的 512B。如果这对您来说比高端写入性能更重要，则可以保留原样。

\n\n

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

\n\n

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

\n