我在 Debian 上有一个大型（> 100TB）ZFS (FUSE) 池，它丢失了两个驱动器。由于驱动器出现故障，我用备件替换它们，直到我可以安排停机并物理更换坏磁盘。
当我关闭系统并更换驱动器时，池开始按预期重新同步，但是当它完成大约 80% 时（这通常需要大约 100 小时），它再次重新启动。
我不确定一次更换两个驱动器是否会造成竞争条件，或者由于池的大小，重新同步器花费的时间太长以至于其他系统进程正在中断它并导致它重新启动，但是在“zpool status”的结果或指向问题的系统日志。
从那以后，我修改了我如何布置这些池以提高重新同步性能，但对让此系统重新投入生产的任何线索或建议表示赞赏。
zpool 状态输出（自上次检查以来，这些错误是新的）：
pool: pod
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: resilver in progress for 85h47m, 62.41% done, 51h40m to go
config:
NAME STATE READ WRITE CKSUM
pod ONLINE 0 0 2.79K
raidz1-0 ONLINE 0 0 …假设我要构建一个非常大的 1PB zpool。我将有一个带有 HBA 的主机单元（可能是 4 端口 LSI SAS 卡），并且我可能将 7 个 45 驱动器的 JBOD 连接到主机单元。
使用 raidz3 执行此操作的基本方法是创建 21 个不同的 15 驱动器 raidz3 vdev（7 个 JBOD 中的每一个 3 个 15 驱动器 vdev），然后从所有 21 个这些 raidz3 vdev 中创建一个池。
这将工作得很好。
这里的问题是，如果您因任何原因丢失一个 vdev，您将丢失整个池。这意味着您绝对不会丢失整个 JBOD，因为那会丢失 3 个 vdev。但是，在邮件列表线程中，有人暗中暗示了一种组织磁盘的方法，这样您就可以确实丢失整个 JBOD。他们说：
“使用戴尔 R720 主机，加上一堆双路径连接到几个 LSI SAS 交换机的戴尔 MD1200 JBOD……我们进行了三重奇偶校验，并且我们的 vdev 成员资格设置为我们最多可以丢失三个 JBOD 并且仍然可以功能（每个 JBOD 一个 vdev 成员磁盘）。”
......我不太确定他们在这里说什么。我认为他们的意思是，不是在一个 HBA 上拥有一个 vdev（所有连续的 15 个（或 12 个，或其他）磁盘），您实际上将 vdev 的奇偶校验驱动器拆分为其他 JBOD，这样您可能会丢失任何 jbod 并且您在其他地方仍然有 N-3 驱动器来覆盖该 vdev …