🔍 1. 先看系统日志：确认错误是否持续
dmesg | grep nvme9n1 | tail -50
看是否 持续报错（比如每几秒一次 I/O error）。
如果只有 一两次，可能是偶发，不一定真坏。
如果 每隔几秒就蹦出 I/O error → 盘基本正在恶化，必须马上换。
如果 只有孤零零的一两条 → 可能是链路瞬断或机房抖动，先别急着拆盘，继续往下验证。
🔍 2. 用 NVMe 工具查健康状态
sudo smartctl -a /dev/nvme9n1
字段 |
正常值 |
说明 |
|
0x00 |
非 0 就报警 |
|
0 |
非 0 → 盘已出现不可修复错误 |
|
不增长 |
持续增加 → 盘正在恶化 |
|
< 100% |
≥ 100% → 盘寿命已尽 |
🔍 3. 查看 NVMe 错误日志
sudo nvme error-log /dev/nvme9n1
看是否有 大量报错，错误条数 >100 或 每次查询都在涨 → 盘片/固件/链路至少有一个在持续出错，建议直接踢盘。
错误条数 个位数且长期不变 → 可再观察一轮，结合业务压力决定是否换。
🔍 4. Pangu 集群整体健康
/apsara/deploy/puadmin summ
/apsara/deploy/puadmin summ（= summary）只能看整体，看不出哪块盘坏，但能快速告诉你“有没有必要继续挖”。
关键栏 |
数值 |
含义 |
Abnormal Chunks |
2 |
只有 2 个 chunk 副本数不足 → 风险极低 |
DISK_OK |
252 / 252 |
所有磁盘状态正常，没有盘被标 fault |
summary 层面看不到设备级细节，无法直接确认 nvme9n1 是否涉及那 2 个异常 chunk。
但 252 块盘全部 DISK_OK，说明 Pangu 还没把 nvme9n1 标记为故障。
Abnormal Chunks 只有 2 个且 副本数并未归零 → 全局数据安全，今晚可以睡个好觉。
DISK_OK 252/252 → 说明 Pangu 还没把这块盘标成 FAULT，但注意：底层硬件报错可能早于集群感知 6~12 小时，所以不能单看这一条就“高枕无忧”。
🔍 5. 检查文件系统是否只读或掉盘
lsblk | grep nvme9n1 mount | grep nvme9n1
如果盘已掉线（lsblk 看不到），或文件系统变只读，说明盘已不可恢复。
lsblk 里消失 → 内核已失联，盘大概率掉线，不用再犹豫了，直接走换盘流程。
mount 状态出现 ro, (read-only) → 内核主动保护，说明 FS 层已不信任该盘，业务写入会挂，必须立即隔离。
