RAID修复成功需查控制器事件日志或/proc/mdstat：硬件RAID用storcli/hpssacli等工具查Rebuild完成条目；软件RAID确认/proc/mdstat无recovery字样且mismatch_cnt为0，并通过fsck验证文件系统一致性。
查看 RAID 控制器日志里有没有修复成功记录
Linux 本身不直接记录“RAID 修复成功”这种语义事件，真正写入修复动作和结果的是硬件 RAID 控制器（如 LSI MegaRAID、Dell PERC、HP Smart Array）或软件 RAID（mdadm）自身的日志机制。你得去查控制器固件层面的日志，而不是 dmesg 或系统日志里翻关键词。
常见做法是用厂商工具读取控制器 event log：
- LSI/Broadcom 卡：用
storcli或旧版MegaCli，例如：storcli /c0/eall/sall show events（查所有物理盘事件）storcli /c0/u0 show events（查逻辑盘u0的事件） - Dell PERC：用
omconfig或perccli，例如：perccli /c0/u0 show events - HP Smart Array：用
hpssacli，例如：hpssacli ctrl slot=0 ld 1 show看状态，再配合hpssacli ctrl slot=0 show config detail查历史事件
注意：这些命令输出里的 Rebuild、Background Initialization、Verify 完成条目才是“修复成功”的原始依据；Failed、Aborted、Stopped 表示中断，不能算成功。
mdadm 软件 RAID 怎么确认 rebuild 是否真完成
软 RAID 没有统一日志文件，/proc/mdstat 是唯一实时可信源。别信 cat /proc/mdstat | grep -q "recovery" 就以为还在跑——它可能卡住、假死、或已 silently 失败。
正确检查方式：
- 运行
cat /proc/mdstat，确认目标阵列（如md0）状态行里没有recovery、resync、check字样，且显示active raid5（或对应级别） - 检查重建进度是否到 100% 并消失：
watch -n1 'cat /proc/mdstat | grep -E "(md[0-9]|recovery|resync)"' - 查内核环缓冲区有没有失败痕迹：
dmesg | grep -i "md.*fail\|raid.*abort\|sector.*read\|device.*removed"
特别注意：mdadm --detail /dev/md0 输出中的 State : 行只反映当前状态快照，不保证过程完整；Rebuild Status : 字段在较新内核中才稳定支持，老版本可能为空或不准。
为什么 dmesg 和 /var/log/messages 不适合查“修复成功”
这两处日志只记录内核或用户态服务的“事件通知”，不是事务性确认。比如：
- 控制器上报“rebuild started”后，可能因掉电、IO hang、坏块过多而静默终止，但
dmesg很少补一条“rebuild failed” -
mdadm在后台线程里做 rebuild，除非出错，否则极少往 syslog 写 completion 消息 - 某些 RAID 卡（尤其低端型号）根本不会把 rebuild 结果上报给 OS，只存本地 NVRAM 日志里
所以依赖 grep -i "rebuild.*done" /var/log/messages 基本无效——你大概率搜不到，搜到了也可能是上次启动残留的旧记录。
离线盘重新上线后，怎么验证数据一致性没被破坏
上线 ≠ 数据完好。RAID 5/6 允许一块（或两块）盘离线，但若离线期间发生写操作且校验块损坏，或 rebuild 过程遇到不可纠正 ECC 错误，恢复后的逻辑盘可能含 silent corruption。
- 必须运行一次全盘校验：
硬 RAID：用控制器自带 verify 或 patrol read 功能（如storcli /c0/u0 start verify）
软 RAID：echo check > /sys/block/md0/md/stat，完成后查/sys/block/md0/md/mismatch_cnt，非 0 就说明有不一致 - 校验通过后，仍需对关键文件系统做
fsck -n（只读检查），尤其是 ext4 的e2fsck -n /dev/md0p1或 XFS 的xfs_repair -n /dev/md0p1 - 别跳过这步：很多“修复成功”的阵列，在 mount 后第一次读取某个 inode 时才暴露元数据损坏
真正可靠的修复闭环，不是看到“rebuild complete”，而是校验无 mismatch + 文件系统 clean + 关键业务文件可打开校验 MD5。
