我有一个由 6 个 RAIDZ 组成的 ZFS 池。其中一个 RAIDZ 已降级，原因是单个 RAIDZ 中丢失了两个磁盘，这两个磁盘的位置非常接近，以至于 ZFS 无法在第二个磁盘发生故障之前从第一个故障中恢复。以下是重新启动后不久“zpool status”的输出：
pool: pod2
state: DEGRADED
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 0h6m, 0.05% done, 237h17m to go
config:
NAME STATE READ WRITE CKSUM
pod2 DEGRADED 0 0 29.3K
raidz1-0 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F165XG ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F1660X ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F1678R ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F1689F ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F16AW9 ONLINE 0 0 0
raidz1-1 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F16C6E ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F16C9F ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F16FCD ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F16JDQ ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17M6V ONLINE 0 0 0
raidz1-2 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17MSZ ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17MXE ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17XKB ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17XMW ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F17ZHY ONLINE 0 0 0
raidz1-3 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F18BM4 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F18BRF ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_W1F18XLP ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09880 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F098BE ONLINE 0 0 0
raidz1-4 DEGRADED 0 0 58.7K
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09B0M ONLINE 0 0 0
spare-1 DEGRADED 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09BEN UNAVAIL 0 0 0 cannot open
disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F49M01 ONLINE 0 0 0 837K resilvered
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0D6LC ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CWD1 ONLINE 0 0 0
spare-4 DEGRADED 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F09C8G UNAVAIL 0 0 0 cannot open
disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F4A7ZE ONLINE 0 0 0 830K resilvered
raidz1-5 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-1CH_Z1F2KNQP ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BML0 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPV4 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BPZP ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ78 ONLINE 0 0 0
raidz1-6 ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQ9G ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQDF ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BQFQ ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0CW1A ONLINE 0 0 0
disk/by-id/scsi-SATA_ST3000DM001-9YN_Z1F0BV7M ONLINE 0 0 0
spares
disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F49M01 INUSE currently in use
disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F4A7ZE INUSE currently in use
disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F49MB1 AVAIL
disk/by-id/scsi-SATA_ST3000DM001-1ER_Z5001SS2 AVAIL
disk/by-id/scsi-SATA_ST3000DM001-1ER_Z5001R0F AVAIL
errors: 37062187 data errors, use '-v' for a list
当第一个磁盘发生故障时，我用热备件替换了它，然后它开始重新同步。在重新同步完成之前，第二个磁盘发生故障，所以我用另一个热备件替换了第二个磁盘。从那时起，它将开始重新同步，完成大约 50%，然后开始吞噬内存，直到它吃掉所有内存并导致操作系统崩溃。
目前，升级服务器上的 RAM 并不是一个简单的选择，而且我不清楚这样做是否能保证解决问题。我知道在这个阶段会有数据丢失，但如果我可以牺牲这一个 RAIDZ 的内容来保留池的其余部分，这是一个完全可以接受的结果。我正在将此服务器的内容备份到另一台服务器，但内存消耗问题迫使我每 48 小时左右重新启动（或崩溃），这会中断我的 rsync 备份，重新启动 rsync 需要时间（一旦它找出中断的位置，就可以恢复，但这需要很长时间）。
我认为 ZFS 尝试处理两个备用替换操作是内存消耗问题的根源，因此我想移除其中一个热备用，以便 ZFS 可以一次处理一个。但是，当我尝试分离其中一个备用时，我收到“无法分离 /dev/disk/by-id/scsi-SATA_ST3000DM001-1CH_W1F49M01：没有有效副本”。也许我可以使用 -f 选项来强制执行该操作，但我不清楚这样做的结果究竟是什么，所以在继续之前，我想看看是否有人有任何意见。
如果我可以让系统进入稳定状态，使其能够保持运行足够长的时间以完成备份，我计划将其关闭以进行大修，但在当前条件下，它陷入了一点恢复循环。
答案1
现在您可以分离 UNAVAIL 磁盘，ZFS 无论如何都不再使用它们了。
您的 RAIDZ-1 设置中有两个磁盘发生故障。您很可能正在查看一些数据丢失，并且应该准备好从备份中恢复。
顺便说一句，根据我使用 OpenSolaris/Solaris11 的经验，RAIDZ 已被证明非常不稳定。我建议不要在任何类型的生产工作负载中使用它。
另外，为了重申 ewwhite 的说法，FUSE 不是您的最佳选择。我会借此机会迁移到更稳定的版本（也许是 FreeBSD 10）。