只看/proc/mdstat不够,必须三层结合:一用/proc/mdstat查逻辑状态快照,二用mdadm --detail验阵列元数据(state、active devices、failed devices等),三用smartctl按盘型加-d参数查smart原始值(如id5、id197、id199)判物理盘真实健康。

只看 /proc/mdstat 不够,它只告诉你“阵列当前有没有掉盘”,但看不出哪块盘快挂了、是不是假故障、有没有隐藏坏道。真要监控软 RAID 健康,得三层结合:内核层看逻辑状态、驱动层查成员盘元数据、硬件层验物理盘寿命。
一、用 /proc/mdstat 快速抓当前运行态
这是最轻量的入口,适合写进定时脚本或告警触发:
- 执行
cat /proc/mdstat,重点盯括号里的状态字符:[UU]表示两块都在线同步,[_U]表示一块已失效,[U_]是另一块掉线 - 看到
recovery = 67.2%或resync = 12.5%,说明正在重建——此时 I/O 压力大,要避免写入高峰 - 若出现
md0 : inactive或整行消失,代表阵列没被自动激活,可能因某盘 UUID 不匹配或元数据损坏
二、用 mdadm --detail 挖逻辑层关键元数据
它告诉你阵列“怎么建的”和“现在认哪些盘”,是判断是否真降级的核心依据:
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
- 运行
sudo mdadm --detail /dev/md0(把md0换成你的设备名) -
State : 后面带
clean是正常关机;带active, not clean说明上次异常断电,下次启动可能无法自动组装 - Active Devices : 数值必须等于你当初设定的盘数(比如 RAID5 设了 4 块,这里就得是 4),少一个就说明有盘被踢出
-
Failed Devices : 非零即危险,再往下找具体是哪块盘标着
faulty - 每个成员盘的状态列如
/dev/sdb1 : active sync是健康,/dev/sdc1 : spare是热备待命,/dev/sdd1 : faulty就该立刻隔离
三、用 smartctl 深挖每块物理盘真实健康
这才是决定“换不换盘”的最终依据——RAID 状态再绿,SMART 里藏着坏扇区也得换:
- 先确认盘类型:
lsblk -d -o NAME,TRAN,MODEL,看TRAN列:是sata就加-d ata;是nvme直接smartctl -a /dev/nvme0n1;USB 盒里通常要-d sat - 别只信最后一行
SMART overall-health self-assessment test result: PASSED,它可能被缓存或屏蔽 - 重点盯原始值(RAW_VALUE):
• ID 5 Reallocated_Sector_Ct > 0 → 已有扇区被重映射,盘开始老化
• ID 197 Current_Pending_Sector > 0 → 有扇区读不出,正等着重映射,随时可能卡死
• ID 199 UDMA_CRC_Error_Count 持续上升 → 数据线或接口接触不良,不是盘本身问题但影响阵列稳定
四、日常可落地的监控建议
不靠人盯,靠机制防漏:
- 把
mdadm --detail和关键盘的smartctl -a输出定期存日志,比如每天凌晨 3 点跑一次 - 配置邮件告警:在
/etc/mdadm/mdadm.conf里设MAILADDR your@domain.com,阵列出问题会自动发信 - 每月手动触发一次校验:
echo "check" > /sys/block/md0/md/sync_action,检查奇偶一致性,输出会记在dmesg里 - 重建中别硬扛:如果
dmesg | grep "I/O error"持续刷屏,说明某盘在重建中途又出错,应暂停重建、换掉问题盘再重来










