我正在运行 FreeNAS 9.3 的特定供应商衍生产品。
我的问题始于我安装了新的 JBOD 机箱以将两个新的 vdev 添加到我的池中，而机箱的主板坏了。在此期间，我看到坏主板上的驱动器出现 SAS 电源错误 - 我的新驱动器实际上每分钟都在反复打开和关闭。
我更换了主板，现在，从大多数指标来看，驱动器运行良好，但当我查看时，ZFS 仍然给我非常奇怪的校验和错误zpool status。我认为当我遇到 SAS 电源问题时，有一些错误的 CoW 写入。
第一个机箱装有 CPU、启动驱动器、RAM 等，通过 mini-SAS 连接到第一个扩展 JBOD 机箱，第二个 JBOD 扩展机箱通过第一个 JBOD 扩展机箱以菊花链形式连接，也通过 mini-SAS 连接。
- [机箱 1：启动驱动器、两个 L2ARC SSD、11/11 驱动器 RAIDZ3-0、1/11 驱动器 RAIDZ3-1] -->mini-SAS 至机箱 2
- [机箱 2：RAID Z3-1 的 10/11 个驱动器，RAID Z3-2 的 6/11 个驱动器] -->mini-SAS 至机箱 3
- [机箱 3：RAIDZ3-2 的 5/11 个驱动器，RAIDZ3-3 的 11/11 个驱动器]
校验和错误不能整齐地映射到任何一个控制器或机箱，但我的直觉是，当我遇到这些电源问题时，写入不同新磁盘的任何数据都会在两个新的 vdev 上被错误写入。
我的 HBA 使用的是良好的 LSI 固件 - 全部使用 20.00.04.00 或 20.00.08.00
我更换了 mini-SAS 电缆，并尝试使用不同的端口，但无济于事。
的输出zpool status显示两个新 vdev 上累积了校验和错误，并且在清理、重新启动或之后zpool clear，最终zpool status将这些 vdev 标记为降级。奇怪的是，它还标记一些属于这些 vdev 的驱动器被标记为已降级，但其各个磁盘的实际错误数都为 0。zdb显示各个驱动器被标记为已降级，因为它们具有太多校验和错误，即使它们的所有校验和错误数实际上都为 0。同样奇怪的是，池级校验和错误显示的数字低于两个问题 vdev 的校验和错误数之和。
zpool status -v0x0持续显示映射到早已删除的 inode 的快照中的永久错误，但似乎无法通过多次清理、重新启动或 来清除zpool clear。此外，其他永久错误时有时无，有时仅显示为十六进制代码 inode，有时显示为最近快照的一部分。我0x0找不到lsof。
我认为池中的元数据可能存在某种数据损坏。
我正在寻找一种方法来彻底删除这些幻影快照，或者在不破坏我的数据的情况下使我的池恢复到健康状态。我怀疑在某个地方，ZFS 正在迭代这些损坏的幻影快照，并导致奇怪的校验和错误以及 vdev 上的降级状态。
我拥有许多重要数据的“冷” LTO 备份，但除此之外，如果我无法修复我的池，我准备设置第二台服务器，将所有内容卸载到“热”的第二台服务器上，在顶层销毁我的池，然后从热备份重新加载。
以下是 的输出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将复制pool到freenas-boot，然后尝试使用zfs destroy删除pool的副本pool/.system并保持freenas-boot副本完整。我能够使用zfs destroy删除所有内容之内 pool/.system中列出的zfs list，但在尝试使用 销毁时pool/.system，zfs destroyshell 返回错误：Cannot iterate filesystems: I/O error。我尝试使用zfs destroy、和标志，按照pool/.system-f-r-ROracle ZFS 文档，但无济于事。
我又开始了一次清理。也许删除副本pool/.system上的内容将允许清理清除幻影快照的元数据错误。poolSystem dataset poolpool/[email protected]
我想知道是否可以逐个重新同步显示为降级的每个磁盘，以便可以放弃未被引用的“坏”元数据。我已经重新同步了两个磁盘，但现在我遇到了一个问题，即重新同步任何其他磁盘都会导致我已经重新同步的其他磁盘同时开始重新同步。我相信这可能是与定期快照任务相关的 ZFS 错误，并且我已经删除了定期快照任务并销毁了所有快照，但我犹豫是否要尝试重新同步另一个降级的驱动器，因为担心所有先前重新同步的磁盘都会再次重新同步，导致我没有任何冗余，最终导致池出现故障。
在禁用定期快照任务并删除所有快照后，我尝试擦除一个磁盘然后重新同步，但已重新同步的三个磁盘又开始重新同步。现在我几乎可以肯定，每个有问题的 RAID-Z3 vdev 都会有两个不同的磁盘可以重新同步，因此如果我尝试重新同步更多磁盘，我将失去每个有问题的 vdev 中的冗余，并且我的池将出现故障。
另一个奇怪的行为是，检查zpool status -v实际上会逐渐增加池的校验和错误计数，但检查zpool status不会。这几乎就像标志-v本身正在迭代导致校验和错误的机制一样。
在我的池上使用是否zdb -c可以以某种方式“修复”这些元数据错误？
答案1
当元数据损坏时，会出现和其他0x0十六进制数字，而不是文件名和其他对象。如果您无法通过销毁受影响的对象（我理解它们指的是快照）来消除它，那么损坏可能太大而无法修复。在这种情况下，我会从备份中恢复池，尤其是当您遇到进一步的奇怪效果（例如损坏的元数据出现和消失）时。
您可以阅读有关如何摆脱大多数问题的方法ZFS 管理指南请点击此处。但是，当您键入 时，ZFS 还会为您提供一个 URL，供您查找解决方案zpool status。