在卷上运行 xfs_repair 之前，我是否应该允许硬件 raid5 阵列重建在换出驱动器之后完成？
目前 xfs_repair 在第 7 阶段的同一位置不断失败：第 7 阶段 - 验证并更正链接数... 在 0x45bf78、xfs_dir3_block 块 0x6a945ef98/0x1000 处检测到元数据损坏 libxfs_bwrite：写入验证程序在 xfs_dir3_block bno 0x6a945ef98/0x8 上失败 xfs_repair：将脏缓冲区释放到空闲列表！xfs_repair：拒绝将损坏的缓冲区写入数据设备！xfs_repair：丢失了对数据设备的写入！
基本上：我是不是很蠢？这是不是以下情况的一个例子：
- “当然，我在重建阵列时看到了数据异常”，应该让它保持 TF 不变并让它完成...可能是明天或后天的某个时候...然后我开始 xfs_repair。
-OR- 2) 我可以在 raid5 硬件阵列重建的同时继续处理 XFS 文件系统，一旦 XFS 文件系统修复完成，就挂载卷，将备份数据 rsync 到主分区，然后继续我的生活，而硬件 raid 重建则继续缓慢地进行，但 IDGAF 因为系统已备份，并且可以花任意长的时间，只要它最终完成即可。
背景信息：我有一个 16TB XFS 文件系统，运行在 HP DL380 的硬件 RAID5 上，配有智能阵列 P410i 控制器。我经常遇到 XFS 文件系统损坏问题。我更换了控制器，并更换了 6 个 4TB 驱动器中的一个，我怀疑这可能是罪魁祸首。
阵列重建需要很长时间，我希望尽快让这个系统恢复运行。运行一天后，硬件恢复/重建现在已完成 56%。对于这个控制器和这种大小的阵列来说，这并不是什么异常。然而，我面临的问题是我想启动 xfs_repair。当我尝试第一个 xfs_repair 时，它说文件系统很脏，需要再次安装。很好。安装/卸载已完成。没什么大不了的。启动 xfs_repair，它开始处理 inode 和元数据损坏。
然后我突然想到，在重建仍在进行时运行 xfs_repair 可能是一个……可以说不是一个好主意。我已将所有数据备份到大型驱动器架备份中，因此我并不担心文件被转移到无人的丢失+找到之地。阵列重建完成后，我将 rsync（较慢的 63TB）驱动器架备份阵列转移到（较快的 16TB）“生产”阵列。理论上，这仍然比删除 16TB 阵列并从备份中进行完整恢复要快……但是：
我是否应该退后一步，把手插进口袋，怒视着 % 完成度 S_L_O_W_L_Y 爪子，让它慢慢地达到 100%，让硬件 raid5 阵列在运行 xfs_repair 之前完成 RAID5 阵列重建——或者——我可以在阵列缓慢、痛苦地重建的同时，继续尝试完成 xfs_repair 吗？