看起来你遇到了一个非常典型的"链路通信故障引发RAID误判"的场景，先别慌，我们一步步拆解问题、给出可行的排查方向：

核心判断：不是多盘同时故障，是链路/控制器/背板出问题了 #

多块硬盘集中在后置面板同时出现SMART 199（UDMA_CRC_Error_Count）非零、内核日志频繁报设备重置和ICRC错误，这种情况几乎不可能是硬盘本身批量故障——硬盘硬件故障通常是随机、孤立的，且很少会统一出现这类"数据传输校验失败"的链路级错误。重启后RAID能重新组装并自动重建，也侧面证明硬盘本身的读写功能是正常的，只是之前的通信故障让系统误判它们失效了。

关键日志/指标解读 #

你的日志里有几个核心线索指向链路问题：

• 内核日志中的mpt3sas_cm0: log_info(0x3112010c)和Power-on or device reset occurred：这是HBA控制器报告的链路异常，频繁触发设备重置
• SMART日志中的Error: ICRC, ABRT、R_ERR response for FIS：这些都是SATA/SAS链路中数据传输校验失败、通信握手出错的典型表现

针对你的问题逐一解答 #

1. 是多盘同时故障还是HBA/背板问题？ #

几乎可以100%确定是HBA控制器的后置通道、后置背板，或者连接背板与HBA的SAS线缆出现了故障，而非硬盘本身批量损坏。

2. 这些硬盘还能信任吗？ #

可以先信任，但需要做验证：

• 等RAID重建完成后，逐个检查硬盘的SMART数据，重点关注除了199项之外的关键健康指标：比如05（重映射扇区计数）、197（当前待映射扇区数）、198（无法校正的扇区数），如果这些指标都正常，说明硬盘本身没有物理坏道之类的硬件问题，之前的错误都是链路故障导致的。
• 可以对这些硬盘做一次全盘读写校验，比如用命令：smartctl -t long /dev/sdX（替换sdX为对应硬盘设备名）执行长自检，或者用dd if=/dev/sdX of=/dev/null bs=1M读取全盘，期间如果没有新的I/O错误或CRC错误出现，就可以放心继续使用。

3. 怎么处理疑似故障的HBA/背板？ #

按优先级从易到难排查：

• 优先更新HBA固件和驱动：你的内核是4.19.181，mpt3sas驱动版本35.00.00.00不算最新，去HBA9500-16i的厂商官网下载对应型号的最新固件，以及适配4.19内核的最新mpt3sas驱动，更新后观察是否还会出现类似错误。
• 检查物理连接：把后置背板与HBA之间的SAS线缆拔插一遍，或者直接更换一根高质量的SAS线缆——线缆松动、老化是引发CRC错误的常见原因。
• 排查背板供电：检查后置背板的供电是否正常，有没有电压不稳的情况；如果有空位，可以把后置的硬盘临时换到前置面板，看是否还会出现错误，以此验证是不是背板本身的问题。
• 更换硬件：如果以上操作都无效，再考虑更换HBA控制器（优先）或后置背板，测试故障是否消失。

额外建议 #

• 紧急备份数据：趁当前RAID正常运行的阶段，把重要数据备份到外部存储设备，避免后续链路故障再次引发RAID崩溃。
• 开启RAID告警：配置系统邮件告警，让RAID控制器或系统在出现硬盘/链路异常时及时通知你，避免等到故障扩大才发现。

备注：内容来源于stack exchange，提问作者michalt