简洁版本：

Question

简洁版本：

您必须反过来做：更换故障池磁盘（用新磁盘或本身），然后从池中分离备用磁盘（以便所有 vdev 都可以使用它）。我假设只要用于替换的磁盘本身没有被替换，备用磁盘就处于繁忙状态。分离此磁盘或其他磁盘只会使情况变得更糟。

另外，我记得 ZoL 没有根据事件自动附加/分离备件的功能，你必须自己编写脚本或使用类似ZFS 事件守护进程。

长版本：

关于你的后续评论

如果 C 盘有故障，那好，我们先更换它，然后将其分离。但这会搞乱我的池，因为 zpool 不记得我以前在镜像 1 中有一个 C 盘 :/

这取决于你如何看待它。如果你从镜像中分离磁盘，它就不再相关了。它可能有缺陷，可能被用在另一个系统上，也可能在制造商保修期内被更换。无论它做什么，你的池都不会关心。

如果您只是分离磁盘，那么它将被降级；如果您提供另一个磁盘（来自自动备用、手动备用或完全手动替换），该磁盘将承担旧磁盘的角色（因此，术语为replace新磁盘完全取代旧磁盘的位置和职责）。

如果需要，您可以将分离的磁盘添加回池中，例如作为备用磁盘（因此初始情况被逆转）。

ZFS 系统上的备件如何工作

备用磁盘只有在自动激活的情况下才真正有意义。Sun 设计的 ZFS 存储阵列有许多类似的磁盘，18 到 48 个磁盘的数量并不罕见。它们由多个 vdev 组成，例如 24 个磁盘系统的 4 x RAID Z2。此外，它们由专门的管理员管理，但没有人可以全天候工作。因此，他们需要某种东西作为第一反应，并且它必须在所有 vdev 上工作，因为任何磁盘都可能随时发生故障。

因此，如果深夜第二个 vdev 中的磁盘发生故障，系统会自动使用两个配置的备用磁盘之一替换故障磁盘，以便池正常工作（例如，对于使用数据库在其上运行的网站的客户，性能相同）。早上，管理员阅读故障报告并排除故障原因：

如果磁盘坏了，他可能会用同一托盘中的替换磁盘将其替换，让其重新镀银，然后热备用磁盘会自动退出并重新执行备用任务，等待另一个坏了的磁盘做出第一响应。
如果没有可用的替换磁盘，他甚至可能将备用磁盘作为新的数据磁盘，暂时将备用磁盘数量减少 1（直到发送另一个替换磁盘并将其作为新的备用磁盘）。
如果只是由于控制器错误而导致磁盘丢失，他甚至可能会用磁盘自身替换它，从而触发与第一种情况相同的备用更新。

如果您按照工程师针对最常见的预期使用场景进行设计的方式思考，那么这将更有意义。这并不意味着您必须完全按照描述进行操作，这可能是行为的一个原因。

回答你的问题

为什么更换 C 盘不足以重建完整池？正如 Oracle 博客和此处所解释的那样，我原本以为我不必为 zfs 分离磁盘即可正确重建池（并且最好保留拔出磁盘的 zpool 状态跟踪，以方便维护）

如上所示，您可以用另一个磁盘或其自身替换池磁盘（备用磁盘将处于空闲状态并继续作为备用磁盘工作），或者您可以分离池磁盘，而备用磁盘将永久承担池磁盘的角色，并且您必须手动添加另一个备用磁盘zpool add poolname spare diskname（可以是分离的磁盘或新磁盘）。

为什么 zpool 一直告诉我备用磁盘“忙”（但实际上并非如此）？

我猜是因为有未完成的 IO。这就可以解释为什么只花了一点时间就完成了操作。

参见下文：如何自动恢复我的备用磁盘？

启用自动备用替换（Solaris/illumos 上的默认设置，Linux 上有点麻烦）
用替换故障池磁盘zpool replace（而不是将其分离）。只有在替换池磁盘后且您没有自动管理的情况下（在我看来，除了特定的池布局和管理情况外，这毫无意义），才需要对备用磁盘执行分离步骤。

Answer 1

简洁版本：

您必须反过来做：更换故障池磁盘（用新磁盘或本身），然后从池中分离备用磁盘（以便所有 vdev 都可以使用它）。我假设只要用于替换的磁盘本身没有被替换，备用磁盘就处于繁忙状态。分离此磁盘或其他磁盘只会使情况变得更糟。

另外，我记得 ZoL 没有根据事件自动附加/分离备件的功能，你必须自己编写脚本或使用类似ZFS 事件守护进程。

长版本：

关于你的后续评论

如果 C 盘有故障，那好，我们先更换它，然后将其分离。但这会搞乱我的池，因为 zpool 不记得我以前在镜像 1 中有一个 C 盘 :/

这取决于你如何看待它。如果你从镜像中分离磁盘，它就不再相关了。它可能有缺陷，可能被用在另一个系统上，也可能在制造商保修期内被更换。无论它做什么，你的池都不会关心。

如果您只是分离磁盘，那么它将被降级；如果您提供另一个磁盘（来自自动备用、手动备用或完全手动替换），该磁盘将承担旧磁盘的角色（因此，术语为replace新磁盘完全取代旧磁盘的位置和职责）。

如果需要，您可以将分离的磁盘添加回池中，例如作为备用磁盘（因此初始情况被逆转）。

ZFS 系统上的备件如何工作

备用磁盘只有在自动激活的情况下才真正有意义。Sun 设计的 ZFS 存储阵列有许多类似的磁盘，18 到 48 个磁盘的数量并不罕见。它们由多个 vdev 组成，例如 24 个磁盘系统的 4 x RAID Z2。此外，它们由专门的管理员管理，但没有人可以全天候工作。因此，他们需要某种东西作为第一反应，并且它必须在所有 vdev 上工作，因为任何磁盘都可能随时发生故障。

因此，如果深夜第二个 vdev 中的磁盘发生故障，系统会自动使用两个配置的备用磁盘之一替换故障磁盘，以便池正常工作（例如，对于使用数据库在其上运行的网站的客户，性能相同）。早上，管理员阅读故障报告并排除故障原因：

如果磁盘坏了，他可能会用同一托盘中的替换磁盘将其替换，让其重新镀银，然后热备用磁盘会自动退出并重新执行备用任务，等待另一个坏了的磁盘做出第一响应。
如果没有可用的替换磁盘，他甚至可能将备用磁盘作为新的数据磁盘，暂时将备用磁盘数量减少 1（直到发送另一个替换磁盘并将其作为新的备用磁盘）。
如果只是由于控制器错误而导致磁盘丢失，他甚至可能会用磁盘自身替换它，从而触发与第一种情况相同的备用更新。

如果您按照工程师针对最常见的预期使用场景进行设计的方式思考，那么这将更有意义。这并不意味着您必须完全按照描述进行操作，这可能是行为的一个原因。

回答你的问题

为什么更换 C 盘不足以重建完整池？正如 Oracle 博客和此处所解释的那样，我原本以为我不必为 zfs 分离磁盘即可正确重建池（并且最好保留拔出磁盘的 zpool 状态跟踪，以方便维护）

如上所示，您可以用另一个磁盘或其自身替换池磁盘（备用磁盘将处于空闲状态并继续作为备用磁盘工作），或者您可以分离池磁盘，而备用磁盘将永久承担池磁盘的角色，并且您必须手动添加另一个备用磁盘zpool add poolname spare diskname（可以是分离的磁盘或新磁盘）。

为什么 zpool 一直告诉我备用磁盘“忙”（但实际上并非如此）？

我猜是因为有未完成的 IO。这就可以解释为什么只花了一点时间就完成了操作。

参见下文：如何自动恢复我的备用磁盘？

启用自动备用替换（Solaris/illumos 上的默认设置，Linux 上有点麻烦）
用替换故障池磁盘zpool replace（而不是将其分离）。只有在替换池磁盘后且您没有自动管理的情况下（在我看来，除了特定的池布局和管理情况外，这毫无意义），才需要对备用磁盘执行分离步骤。

简洁版本：

答案1

简洁版本：

长版本：

关于你的后续评论

ZFS 系统上的备件如何工作

回答你的问题

相关内容