use*_*467 8 freebsd zfs freenas checksum zpool
我正在运行 FreeNAS 9.3 的供应商特定衍生产品。
当我安装了一个新的 JBOD 机箱以将两个新的 vdev 添加到我的池中时，我的麻烦就开始了，而机箱的板子有问题。在此期间，我看到坏板上的驱动器出现 SAS 电源错误——我的新驱动器每分钟反复有效地打开和关闭。
我更换了主板，现在，从大多数角度来看，驱动器运行良好，但是当我查看zpool status. 我认为当我遇到 SAS 电源问题时，有一些糟糕的 CoW 写入。
带有 CPU、引导驱动器、RAM 等的第一个机箱通过 mini-SAS 连接到第一个扩展 JBOD 机箱，第二个 JBOD 扩展机箱通过第一个 JBOD 扩展机箱菊花链连接，也通过 mini-SAS。
校验和错误并不能完美地映射到任何一个控制器或机箱，但我的预感是，当我遇到这些电源问题时，无论写入到不同新磁盘的任何数据都在两个新 vdev 上写入错误。
我的 HBA 使用了良好的 LSI 固件——全部都在 20.00.04.00 或 20.00.08.00
我已经更换了迷你 SAS 电缆，并尝试使用不同的端口，但无济于事。
的输出zpool status显示在两个新 vdev 上累积的校验和错误，并且在经过清理、重新启动或 之后zpool clear，最终将zpool status这些 vdev 标记为已降级。奇怪的是，它还将一些属于那些 vdevs 的驱动器标记为降级，但它们单个磁盘的实际错误计数都是 0。zdb表明单个驱动器被标记为降级，因为它们有太多的校验和错误，即使他们所有的校验和错误计数实际上都是 0。同样奇怪的是，池级别的校验和错误显示的数字低于来自两个问题 vdev 的校验和错误加在一起的数字。
zpool status -v在映射到0x0早已被删除的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/.system@auto-20160720.2300-2d:<0x0>
通过 FreeNAS GUI，我尝试将System dataset poolfrom poolover复制到freenas-boot，然后尝试使用zfs destroy删除pool副本pool/.system并保持freenas-boot副本完好无损。我能够使用zfs destroy删除中 pool/.system列出的所有内容zfs list，但是在尝试使用 销毁pool/.system时zfs destroy，shell 返回错误：Cannot iterate filesystems: I/O error。我试图zfs destroy在pool/.system用的-f，-r和-R标志，具体根据甲骨文ZFS文件，但没有成功。
我又开始了一次磨砂。也许消除内容pool/.system的pool副本System dataset pool将允许擦洗，以清除与幻影快照元数据错误pool/.system@auto-20160720.2300-2d。
我想知道是否可以将每个显示为降级的磁盘一个一个地重新同步，以便可以放弃未被引用的“坏”元数据。我已经重新同步了两个磁盘，但现在我遇到了一个问题，即重新同步任何额外的磁盘会导致我已经重新同步的其他磁盘同时再次开始重新同步。我相信这可能是一个与定期快照任务相关的 ZFS 错误，我已经删除了我的定期快照任务并销毁了我的所有快照，但我害怕尝试重新同步另一个降级的驱动器所有以前重新同步的磁盘将再次重新同步，让我没有任何冗余，最终导致池出现故障。
在禁用我的定期快照任务并删除我的所有快照后，我尝试擦除一个磁盘然后重新同步它，但是我已经重新同步的三个磁盘又开始重新同步。现在我几乎可以肯定，每个问题 RAID-Z3 vdev 都会有两个不同的磁盘可以重新同步，所以如果我尝试重新同步更多磁盘，我将失去每个问题 vdev 和我的池中的冗余会出错。
另一种奇怪的行为是检查zpool status -v实际上会逐渐增加池的校验和错误计数，但检查zpool status不会。就好像-v标志本身正在迭代导致校验和错误的任何机制。
zdb -c在我的池上使用是否能够“修复”这些元数据错误？
小智 5
0x0当元数据损坏时，会出现 和其他十六进制数字，而不是文件名和其他对象。如果您无法通过销毁受影响的对象来摆脱它（我理解它们指的是快照），那么损坏可能太大而无法修复。在这种情况下，我会从备份中恢复池，特别是当您遇到更奇怪的效果（例如损坏的元数据出现和消失）时。
您可以在此处的 ZFS 管理指南中阅读有关如何解决大多数问题的方法。但 ZFS 还为您提供了一个 URL，让您在键入时可以在其中查找解决方案zpool status。
| 归档时间： |
|
| 查看次数： |
2173 次 |
| 最近记录： |