StorCLI 硬件坏盘与 Linux 系统分区映射排查 SOP

当 Linux 文件系统报 Input/output error、dmesg 出现 critical medium error 或 XFS metadata I/O error 时，底层物理介质往往已经出现坏道。硬件 RAID 卡把物理盘屏蔽成了虚拟盘，导致「系统盘符」与「物理槽位」之间隔着好几层，必须借助 StorCLI 一步步反推才能定位到坏盘的真实槽位。

本文给出一份生产可用的完整排查 SOP，从内核日志到槽位定位、从 SMART 误判到换盘恢复，全链路打通。

说明：文中磁盘型号、挂载点、Enclosure/Slot 编号、sector 地址均为示例占位，仅用于演示流程，请以实际环境输出为准。

一、背景与问题现象

Linux 运维中常见的"诡异"故障：

ls / cat 报 Input/output error
dmesg 持续刷 critical medium error
XFS 文件系统被强制 Shutting down filesystem
业务进程读文件时随机崩溃

这些现象的根因往往是物理介质坏道。

一个容易踩的坑：SMART 信息可能显示正常（Elements in grown defect list: 0）。原因有二：

坏道尚未触发写重映射（write remap），Grown Defect List 还没增长
坏道集中在某个未读到的区域，SMART 巡检还没扫到

因此不能只看 smartctl，必须通过阵列卡工具 StorCLI 直接核查物理盘的 Media Error Count。

二、整体排查链路

┌──── OS 层（带内）────────┐      ┌──── 硬件层（带外）──────┐
│                          │      │                          │
│ dmesg                    │      │ iDRAC Lifecycle Log      │
│  → dev sdX + sector      │      │  → VDR58 (VD 层坏块)     │
│                          │      │  → PDR64 (PD 层介质错误) │
│ smartctl（可能误判正常）  │      │  → Disk 12 in Backplane 1│
└────────────┬─────────────┘      └─────────────┬────────────┘
             │                                  │
             └──────────────┬───────────────────┘
                            ▼
            ┌────────────────────────────────────┐
            │   StorCLI 三步反推链条              │
            │                                    │
            │   ① OS 盘符  → VD 编号             │
            │   ② VD 编号  → DG 编号             │
            │   ③ DG 编号  → Slot 物理槽位       │
            │                                    │
            │   （与 iDRAC 报的 Disk/Backplane    │
            │     交叉印证,完全一致才放心）       │
            └────────────────┬───────────────────┘
                             ▼
              storcli /c0/e64/s12 show all   ← 查 Media Error Count
                             │
                             ▼
                > 0 → 物理损坏 → 下线 + 换盘
                = 0 → 逻辑损坏 → xfs_repair

双线索交叉印证是本 SOP 的核心方法论：

OS 层（dmesg）告诉你「哪个系统盘符出错」
带外层（iDRAC）告诉你「硬件层认定哪块物理盘出错」
StorCLI 把两者串起来，并提供最终的 Media Error Count 裁决

核心难点：硬件 RAID 卡隔离了物理接口，OS 只看到 VD（虚拟盘），必须靠 DG 反推到物理 Slot；带外日志则能绕过 OS 直接给出 PD 层结论，是最可靠的独立证据。

三、步骤一：查看内核日志，锁定异常 OS 盘符

查看最近的内核日志，确认哪个系统盘符抛出了物理介质错误：

dmesg -T | tail -n 30

实际终端输出参考：

[Sat Jul 25 06:53:54 2026] blk_update_request: critical medium error, dev sdf, sector 881403072
[Sat Jul 25 06:53:54 2026] XFS (sdf): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x348924c0 len 32 error 61
[Sat Jul 25 06:53:54 2026] XFS (sdf): Corruption of in-memory data detected. Shutting down filesystem

诊断要点：

dev sdf → 出问题的 OS 盘符是 /dev/sdf
critical medium error → 内核已确认是物理介质读取失败，不是文件系统逻辑错
sector 881403072 → 出问题的扇区号（用于后续核实）
XFS ... Shutting down filesystem → XFS 检测到元数据 I/O 错误，自我保护强制下线

💡 也可以用 journalctl -k --since "1 hour ago" 看更结构化的内核日志。

四、步骤一并：查看 iDRAC 带外生命周期日志（交叉印证）

OS 层日志能看到「现象」（哪个 sdX 出错），但看不到「硬件层发生了什么」。带外日志（Out-of-Band）走的是 BMC/iDRAC 独立通道，不依赖 OS，能在 OS 宕机、内核 panic、甚至重启后仍保留完整硬件事件记录。

对 Dell 服务器，登录 iDRAC Web → Maintenance → Lifecycle Log（或 racadm getsel / racadm getlclog 命令行）查看。

4.1 iDRAC Lifecycle 日志示例（已脱敏）

2026-07-26 04:28:18  VDR58  Bad block medium error is detected at block 0x34906050
                            on Virtual Disk 228 on RAID Controller in SL N.
2026-07-26 04:28:18  PDR64  An unrecoverable disk media error occurred on Disk 12
                            in Backplane 1 of RAID Controller in SL N. Part Number =
2026-07-26 01:23:05  VDR58  Bad block medium error is detected at block 0x251dfb90
                            on Virtual Disk 228 on RAID Controller in SL N.
2026-07-26 01:23:05  PDR64  An unrecoverable disk media error occurred on Disk 12
                            in Backplane 1 of RAID Controller in SL N. Part Number =

说明：SL N 为服务器机柜/槽位物理标识（已脱敏占位）；其余编号、扇区地址均为示例。

4.2 日志字段解读

字段	含义
`VDR58`	iDRAC 事件类型码：Virtual Disk RAID 相关告警（VD 层坏块）
`PDR64`	iDRAC 事件类型码：Physical Disk RAID 相关告警（PD 层介质错误）
`Virtual Disk 228`	出问题的虚拟盘编号（与本文示例 VD228 完全对得上）
`Disk 12 in Backplane 1`	物理盘位置：Backplane 1 的第 12 槽（与 StorCLI 的 `e64/s12` 对应）
`block 0x34906050`	坏块的逻辑块地址（LBA）
`SL N`	服务器所在机柜/槽位物理标识

4.3 双线索交叉印证

信息层	日志源	关键字段	在本例中的值
OS 层	dmesg	`dev sdf` + `sector 881403072`	OS 盘符 sdf
VD 层	iDRAC VDR58	`Virtual Disk 228` + `block 0x34906050`	虚拟盘 VD228
PD 层	iDRAC PDR64	`Disk 12 in Backplane 1`	物理盘 Slot 12
PD 健康	StorCLI	`Media Error Count = 1198`	物理介质损坏

三层信息完全自洽：

dmesg:  dev sdf        ──┐
                          ├──  →  VD 228  ──→  Disk 12 (Backplane 1)  ──→  Media Error 1198
iDRAC:  VD228 / Disk12  ─┘

带外日志最大的价值：即使 OS 层完全没记下 dmesg（被滚动覆盖、或系统直接宕机），iDRAC 仍能独立告诉你坏的是哪块盘。

4.4 racadm 命令行采集（无需 Web 界面）

# 查看系统事件日志 SEL（短日志）
racadm getsel -o

# 查看生命周期日志 LCLOG（详细，含 VDR/PDR 事件）
racadm getlclog

# 导出全部生命周期日志到本地
racadm getlclog -f /tmp/lclog.txt

💡 远程批量采集可走 SSH：ssh root@<idrac-ip> racadm getlclog，配合 Ansible 可一键收集机房所有机器的带外日志做集中告警。

五、步骤二：OS 盘符 → VD → DG → Slot 三步反推

4.1 OS 盘符 → VD（Virtual Drive）编号

./storcli64 /c0/vall show all | awk '/^VD[0-9]+ Properties/ { vd=$1 } /^OS Drive Name/ { print vd "\t" $5 }'

输出参考：

...
VD228   /dev/sdf
...

结论：/dev/sdf 对应虚拟盘 VD228。

说明：/c0 表示 controller 0，/vall 表示所有 VD。StorCLI 会列出每个 VD 的属性块，awk 同时抓取 VD 编号和它对应的 OS 盘符。

4.2 VD → DG（Drive Group）编号

./storcli64 /c0/vall show

输出参考：

--------------------------------------------------------------
DG/VD  TYPE  State Access Consist Cache Cac sCC    Size Name
--------------------------------------------------------------
11/228 RAID0 Optl  RW     Yes     RWBD  -   OFF 2.182 TB

读法：DG/VD 列格式是 <DG>/<VD>，即 11/228 表示 DG=11，VD=228。

斜线左侧（11）→ DG 编号（磁盘组）
斜线右侧（228）→ VD 编号（虚拟盘，与上一步对得上）

结论：VD228 属于磁盘组 DG 11。

4.3 DG → 物理 Slot（槽位）与 Device ID

./storcli64 /c0/eall/sall show

输出参考：

----------------------------------------------------------------------------
EID:Slt DID State DG     Size Intf Med SED PI SeSz Model            Sp Type
----------------------------------------------------------------------------
64:12    1   Onln 11 2.182 TB SAS  HDD N   N  512B XXX-XXXXXXX     U  -

读法：

EID:Slt = 64:12 → Enclosure 64，Slot 12（物理位置）
DID = 1 → Device ID
DG = 11 → 上一步查出的 DG 编号，用这列过滤
State = Onln → 在线状态

结论：DG 11 对应的物理盘位于 Enclosure 64 / Slot 12。

4.4 链路推导总结

/dev/sdf  →  VD 228  →  DG 11  →  Enclosure 64 / Slot 12
 OS 盘符     虚拟盘      磁盘组      物理槽位

后续所有针对这块物理盘的操作，路径都是 /c0/e64/s12。

六、步骤三：验证 SMART 与底层物理 Error

5.1 smartctl 查看物理盘 SMART（可能误判）

利用上一步推导出的 Slot 12 编号，透过 RAID 卡读取物理盘（注意是 megaraid,<N>，N 是 Device ID 不是 Slot）：

smartctl -a -d megaraid,1 /dev/sdf

输出参考：

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
...
Elements in grown defect list: 0
Total uncorrected errors: 0

⚠️ 关键陷阱：此时 SMART 显示 OK、grown defect list: 0，不能据此判定磁盘健康。坏道若尚未触发写重映射，Grown Defect List 不会增长。必须用下一步的 StorCLI 介质错误计数核实。

5.2 StorCLI 核查 Media Error Count（判定真凶）

./storcli64 /c0/e64/s12 show all | grep -i "Media Error"

实际终端输出参考：

Media Error Count = 1198

5.3 判定标准

Media Error Count	结论	处置
`= 0`	物理盘介质正常，多为逻辑文件系统错乱	尝试 `xfs_repair` 修复
`> 0`（如 1198）	磁头/盘片存在严重物理损伤	必须更换物理盘

💡 通常 Media Error Count 一旦持续增长就不会自愈，且会随读取扩散。发现 > 0 立即下线换盘，不要等。

七、坏盘下线与更换 SOP

确认 Media Error Count 居高不下时，严格按以下步骤下线并通知机房换盘。

6.1 数据抢救（按需）

如果盘上还有可读数据需要备份，尝试只读跳过日志重放挂载（避免 XFS replay 二次损坏）：

mount -o ro,norecovery /dev/sdf /data6
rsync -avP /data6/重要目录/ /data_backup/

⚠️ 抢救数据可能触发更多坏道读取，能救多少算多少，不要反复重试以免加重损伤。

6.2 卸载分区与逻辑下线

# 1. 退出挂载目录,清理占用进程
cd /tmp
fuser -k -9 /data6

# 2. 卸载文件系统(-l 懒卸载,即使忙也立即解除挂载)
umount -l /data6

# 3. 把阵列卡上的 Slot 12 设为 Offline(逻辑下线,不影响同 DG 其它盘)
./storcli64 /c0/e64/s12 set offline

6.3 点亮物理定位灯（通知机房换盘）

./storcli64 /c0/e64/s12 start locate

机房人员根据亮起的物理定位灯（前面板蓝色/琥珀色 LED）找到对应盘位，物理拔插更换。

6.4 换盘后恢复

机房换盘完成后：

# 1. 熄灭定位灯
./storcli64 /c0/e64/s12 stop locate

# 2. 确认新盘已识别(应为 UGood 未配置状态)
./storcli64 /c0/e64/s12 show

# 3. 重建虚拟盘(单盘 RAID0 或按原阵列级别)
./storcli64 /c0 add vd r0 drives=64:12

# 4. 重新格式化并挂载
mkfs.xfs -f /dev/sdf
mount -a

💡 若原 DG 是多盘 RAID（如 RAID1/5/10），换盘后是rebuild 重建而非新建 VD，命令应为：
```bash
./storcli64 /c0/e64/s12 insert dg=11

或

./storcli64 /c0/e64/s12 start rebuild
```

八、StorCLI 命令速查表

场景	命令
查所有 VD 概览	`./storcli64 /c0/vall show`
查所有 VD 详细（含 OS 盘符）	`./storcli64 /c0/vall show all`
查所有物理盘（Slot/DG/State）	`./storcli64 /c0/eall/sall show`
查某物理盘详情（含 Media Error）	`./storcli64 /c0/e64/s12 show all`
物理盘 Offline	`./storcli64 /c0/e64/s12 set offline`
物理盘 Online	`./storcli64 /c0/e64/s12 set online`
点亮定位灯	`./storcli64 /c0/e64/s12 start locate`
熄灭定位灯	`./storcli64 /c0/e64/s12 stop locate`
控制器整体状态	`./storcli64 /c0 show`
控制器告警事件	`./storcli64 /c0 show events`

九、常见坑与排查技巧

8.1 smartctl 显示 OK 但实际坏道

原因：坏道未触发写重映射，Grown Defect List 不增长。

对策：永远以 StorCLI 的 Media Error Count 为准，smartctl 仅作参考。

8.2 `megaraid,N` 的 N 是什么

是 Device ID（DID 列），不是 Slot 号。本文示例中 Slot 12 的 DID 是 1，所以用 megaraid,1。混用会读到错误的盘。

8.3 `set offline` 后盘去哪了

offline 是逻辑下线（VD 中剔除），物理盘仍在线供电。完全断电需 spindown 或物理拔盘。生产环境通常 offline 即可。

8.4 VD 编号很大（如 VD228）正常吗

正常。Broadcom/LSI 阵列卡 VD 编号会随历史创建/删除累积，228 只是历史计数，不代表有 228 个虚拟盘。

8.5 XFS 反复 Shutting down

文件系统层是受害者。先解决底层物理坏道，再谈 xfs_repair。在坏盘上跑 repair 只会越修越坏。

十、流程总结

发现 I/O error
     │
     ├──────────── 带内 ────────────┐    ┌──── 带外 ────┐
     ▼                              │    │              │
dmesg 确认 dev sdX                  │    │ iDRAC 查     │
+ critical medium error             │    │ VDR58/PDR64  │
     │                              │    │ Disk/Backplane│
     ▼                              │    │      │       │
storcli vall show all → VD?         │    └──────┼───────┘
     │                              │           │
     ▼                              │           │
storcli vall show → DG?             │           │
     │                              │           │
     ▼                              │           │
storcli eall/sall show → Slot?  ◀───┴───────────┘
     │                            （三层交叉印证）
     ▼
storcli e64/s12 show all | grep "Media Error"
     │
     ├── = 0  →  xfs_repair 修文件系统
     │
     └── > 0  →  set offline
                   │
                   ▼
                start locate → 机房换盘 → stop locate
                   │
                   ▼
                重建 VD / rebuild → mkfs.xfs → mount

十一、核心原则

物理介质问题先于文件系统问题：XFS 报错时先查底层，别盲目 xfs_repair
SMART 不是万能：Grown Defect List 可能滞后，以 StorCLI Media Error Count 为准
三步反推链是核心：OS 盘符 → VD → DG → Slot，缺一不可
带内 + 带外双线索交叉印证：dmesg/iDRAC/StorCLI 三层结论一致才下结论；OS 宕机时 iDRAC 是唯一证据
下线前先抢救数据：ro,norecovery 只读挂载，能救多少算多少
换盘先看阵列级别：RAID0 是新建 VD，RAID1/5/10 是 rebuild

按这套 SOP 走，硬件坏盘定位从「猜盘」变成「可复现的推导」，单机 10 分钟内可锁定具体槽位。

一、背景与问题现象

二、整体排查链路

三、步骤一：查看内核日志，锁定异常 OS 盘符

四、步骤一并：查看 iDRAC 带外生命周期日志（交叉印证）

4.1 iDRAC Lifecycle 日志示例（已脱敏）

4.2 日志字段解读

4.3 双线索交叉印证

4.4 racadm 命令行采集（无需 Web 界面）

五、步骤二：OS 盘符 → VD → DG → Slot 三步反推

4.1 OS 盘符 → VD（Virtual Drive）编号

4.2 VD → DG（Drive Group）编号

4.3 DG → 物理 Slot（槽位）与 Device ID

4.4 链路推导总结

六、步骤三：验证 SMART 与底层物理 Error

5.1 smartctl 查看物理盘 SMART（可能误判）

5.2 StorCLI 核查 Media Error Count（判定真凶）

5.3 判定标准

七、坏盘下线与更换 SOP

6.1 数据抢救（按需）

6.2 卸载分区与逻辑下线

6.3 点亮物理定位灯（通知机房换盘）

6.4 换盘后恢复

或

八、StorCLI 命令速查表

九、常见坑与排查技巧

8.1 smartctl 显示 OK 但实际坏道

8.2 megaraid,N 的 N 是什么

8.3 set offline 后盘去哪了

8.4 VD 编号很大（如 VD228）正常吗

8.5 XFS 反复 Shutting down

十、流程总结

十一、核心原则

8.2 `megaraid,N` 的 N 是什么

8.3 `set offline` 后盘去哪了