我正在运行FreeNAS 9.3的供应商特定衍生产品。
当我安装了一个新的JBOD机箱，将两个新的vdevs添加到我的池中，并且机箱中有一个坏的主板时，我的麻烦就开始了。 在这段时间里，我发现硬盘上的硬盘出现了SAS供电错误 – 我的新硬盘每分钟都会反复打开和closures。
我更换了主板，现在，通过大多数措施，驱动器运行良好，但是当我查看zpool status时，ZFS仍然给我非常奇怪的校验和错误。 当我遇到SAS电源问题时，我认为CoW有一些不好的写法。
带有CPU，引导驱动器，RAM等的第一个机箱通过mini-SAS连接到第一个扩展JBOD机箱，第二个JBOD扩展机箱通过第一个JBOD扩展机箱（也通过mini-SAS）以菊花链方式连接。
校验和错误不能整齐地映射到任何一个控制器或机箱，但是我的直觉是，当我遇到这些电源问题时，无论写入到不同的新磁盘的数据是不是写在两个新的vdevs上。
我的HBA采用了好的LSI固件 – 全部在20.00.04.00或20.00.08.00
我更换了迷你SAS电缆，并尝试使用不同的端口，无济于事。
zpool status的输出显示在两个新的vdevs上累积的校验和错误，在scrub，reboot或zpool clear ，最终zpool status这些vdevs标记为降级。 奇怪的是，它也将属于这些vdevs的一些驱动器标记为降级，但是它们的单个磁盘的实际错误计数均为0. zdb显示单个驱动器由于校验和错误太多而被标记为降级尽pipe他们所有的校验和错误计数实际上是0.也奇怪的是，池级别的校验和错误显示的数字比两个问题vdevs加在一起的校验和错误less。
zpool status -v在映射到长久被删除的0x0 inode的快照中持久地显示永久性错误，但似乎无法被多个scrubs，reboots或zpool clear 。 另外，其他的永久性错误也会浮现出来，有时候只会显示为hex代码节点，而其他时间则是最近快照的一部分。 我用lsof找不到任何0x0 。
我相信池中的元数据可能会有某种数据损坏。
我正在寻找一种方法来手术去除这些幻影快照，否则返回我的池到一个健康的状态，而不会破坏我的数据。 我怀疑ZFS正在迭代这些损坏的幻影快照，并在vdevs上造成奇怪的校验和错误和降级状态。
我有很多重要数据的“冷”LTO备份，否则，如果我不能修复我的池，我准备build立第二台服务器，将所有内容卸载到“热”第二台服务器上，销毁我的池在顶层，然后从热备份重新加载。
以下是zpool status -v的输出：
[root@Jupiter] ~# zpool status -v pool: freenas-boot state: ONLINE status: One or more devices are configured to use a non-native block size. Expect reduced performance. action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool. scan: resilvered 944M in 0h17m with 0 errors on Tue Aug 9 11:56:28 2016 config: NAME STATE READ WRITE CKSUM freenas-boot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da46p2 ONLINE 0 0 0 block size: 8192B configured, 8388608B native da47p2 ONLINE 0 0 0 block size: 8192B configured, 8388608B native errors: No known data errors pool: pool 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://illumos.org/msg/ZFS-8000-8A scan: scrub in progress since Fri Sep 9 22:43:51 2016 6.27T scanned out of 145T at 1.11G/s, 35h27m to go 0 repaired, 4.33% done config: NAME STATE READ WRITE CKSUM pool DEGRADED 0 0 118 raidz3-0 ONLINE 0 0 0 gptid/ac108605-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ac591d4e-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ac92fd0d-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/accd3076-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ad067e97-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ad46cbee-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ad91ba17-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/adcbdd0a-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ae07dc0d-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ae494d10-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/ae93a3a5-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 raidz3-1 ONLINE 0 0 0 gptid/12f6a4c5-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/511ea1f9-1932-11e6-9b1e-0cc47a599098 ONLINE 0 0 0 gptid/14436fcf-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/14f50aa3-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/159b5654-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/163d682b-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/16ee624e-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/1799dde3-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/184c2ea4-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/18f51c30-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 gptid/19a861ea-c929-11e5-8075-0cc47a599098 ONLINE 0 0 0 raidz3-2 DEGRADED 0 0 236 gptid/5f80fc42-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/60369e0f-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/60e8234a-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/61a235f2-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/62580471-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/6316a38a-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/63d4bce8-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/ebfc2b99-6893-11e6-9b09-0cc47a599098 ONLINE 0 0 0 gptid/654f143a-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/66236b33-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/66eda3f6-4e00-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors raidz3-3 DEGRADED 0 0 176 gptid/c77a9da9-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/c83e100e-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/c8fd9ced-4e02-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/c9bb21ba-4e02-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/ca7a48db-4e02-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/cb422329-4e02-11e6-b7cf-0cc47a599098 DEGRADED 0 0 0 too many errors gptid/cbfe4c21-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/ccc43528-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/cd93a34c-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/ce622f51-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 gptid/cf2591d3-4e02-11e6-b7cf-0cc47a599098 ONLINE 0 0 0 cache gptid/aedd3872-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 gptid/af559c10-265c-11e5-9a02-0cc47a599098 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: <0x357>:<0x2aef3> <0x37b>:<0x397285> pool/[email protected]:<0x0>
通过FreeNAS GUI，我尝试将System dataset pool的System dataset pool复制到freenas-boot ，然后尝试使用zfs destroy删除pool/.system freenas-boot的pool副本，并使freenas-boot副本保持不变。 我能够使用zfs destroy删除zfs list列出的pool/.system所有内容，但是在尝试使用zfs destroy销毁pool/.system时，shell返回了以下错误： Cannot iterate filesystems: I/O error 。 根据Oracle ZFS文档 ，我使用-f ， -r和-R标志试图在pool/.system上尝试了zfs destroy ，但是无济于事。
我又开始磨砂。 也许在System dataset pool的pool副本中删除pool/.system的内容将允许使用幻影快照pool/[email protected]清理元数据错误。
我想知道是否有可能将每个显示为降级的磁盘重新popup，以便可以放弃不被引用的“坏”元数据。 我已经重新安装了两个磁盘，但是现在我遇到了一个问题，其中重新启动任何其他磁盘会导致其他已经重新启动的磁盘在同一时间再次开始重新同步。 我相信这可能是一个与定期快照任务相关的ZFS错误 ，而且我已经提前删除了我的定期快照任务，并且销毁了我所有的快照，但是我仍然犹豫是否需要重新尝试另一个降级的驱动器所有以前重新设置的磁盘将再次恢复原状，使我没有任何冗余，最终导致出现故障池。
在禁用了我的定期快照任务并删除了所有的快照之后，我尝试擦除一个磁盘，然后重新同步它，但是我已经重置的三个磁盘又重新开始重新同步。 现在我几乎可以肯定的是，每个问题RAID-Z3 vdev都会有两个不同的磁盘，所以如果我尝试重新启动更多的磁盘，我将在每个问题vdevs和我的池中失去冗余会过错。
另一个奇怪的行为是检查zpool status -v实际上增加了池的校验和错误计数，但是检查zpool status不会。 就好像-v标志本身正在迭代任何引起校验和错误的机制。
会在我的池上使用zdb -c以某种方式能够“修复”这些元数据错误？
当元数据损坏时，会出现0x0和其他hex数字，而不是文件名和其他对象。 如果你不能通过摧毁受到影响的物体（我明白它们指的是快照）来消除它，那么伤害可能太大而无法修复。 在这种情况下，我会从备份恢复池，特别是当你有更多奇怪的效果，如破碎的元数据出现和消失。
您可以在这里阅读有关如何摆脱ZFSpipe理指南中大多数问题的方法。 但ZFS也为您提供了一个URL，在键入zpool status时可以查找解决scheme。