multipath服务启动后/dev/mapper/为空，主因是未识别到多路径scsi设备；需检查lun映射、多路径可见性、blacklist配置、内核模块加载，并用multipath -v2调试。
为什么 multipath 服务启动后设备没出现在 /dev/mapper/
常见现象是执行 systemctl start multipathd 后，ls /dev/mapper/ 为空，或只有 control 设备。这通常不是服务没起来，而是没有识别到符合多路径条件的 SCSI 设备。
关键检查点：
- 确认存储阵列已正确映射 LUN 到主机，且主机端能看到多个路径（例如
/dev/sdb、/dev/sdc、/dev/sdd等），用lsblk或lsscsi -s验证 - 运行
multipath -v2（不是-v3）手动触发发现——它会输出详细匹配过程，重点看是否出现blacklisted或skip: no path - 检查
/etc/multipath.conf中是否误启用了blacklist，尤其注意devnode "^sd[a-z]"这类默认规则会把所有本地 SATA 盘也拦掉；建议先注释整个blacklist段再试 - 确认内核模块已加载：
lsmod | grep dm_multipath，若无输出需执行modprobe dm_multipath并设为开机加载
multipath.conf 最小可用配置怎么写
新手常被默认配置吓退，其实生产环境起步只需 4 行有效配置。其余全删或注释，避免干扰。
编辑 /etc/multipath.conf，确保包含：
defaults {
user_friendly_names yes
}
devices {
device {
vendor "NETAPP"
product "LUN"
path_grouping_policy multibus
failback immediate
}
}
说明：
-
vendor和product必须与scsi_id -g -u -d /dev/sdb输出中的VENDOR和PRODUCT完全一致（大小写敏感），不同厂商值不同，如"DGC"、"IBM"、"HITACHI" -
path_grouping_policy multibus表示所有路径都参与 I/O，适合大多数中低端阵列；高端阵列（如 VMAX）需用group_by_prio+path_checker tur - 不要加
wwid字段——那是单设备硬编码，无法泛化；靠vendor/product匹配才是可维护做法
multipath -ll 显示 paths=0 或状态为 failed
这表示 multipathd 认为路径不可用，但底层 SCSI 设备可能仍能读写。典型原因不是线缆松动，而是路径未通过 path_checker 探活。
排查顺序：
- 查日志：
journalctl -u multipathd | grep -i "checker\|fail"，看具体哪个设备、哪个路径失败 - 手动测试路径连通性：
sg_turs /dev/sdb（需装sg3_utils），返回非零即路径不通；部分旧阵列不支持 TUR，得换readsector0检查方式 - 临时修改 checker：
multipathd -k"set path_checker readsector0 sdb"，再multipath -r重载；若恢复，说明原配置的path_checker tur不兼容该阵列 - 检查 HBA 卡驱动是否启用 NPIV 或 ALPA 模式冲突，某些 QLogic 卡需禁用
qla2xxx.qlport_down_retry=1参数
应用层如何安全使用 multipath 设备
别直接在 /dev/mapper/mpathX 上建文件系统——这是最常见误操作。设备名可能因重启、路径增减而变化（mpatha → mpathb）。
正确做法：
- 用
wwid创建符号链接：ln -s /dev/mapper/<code>$(cat /sys/block/mpathX/device/wwid)/dev/disk/by-id/scsi-$(cat /sys/block/mpathX/device/wwid | tr -d '[:space:]')，再让 LVM 或文件系统引用该路径 - LVM 场景下，直接将
/dev/mapper/mpathX加入 PV，因为 LVM 自带 UUID 识别，不受设备名变动影响：pvcreate /dev/mapper/mpathX - 挂载时用
UUID=...或NAME=...（LVM 逻辑卷名），永远别写死/dev/mapper/mpathX - 如果必须脚本化识别，用
multipath -j | jq -r '.maps[].wwid'解析 JSON 输出，比解析multipath -ll文本可靠得多
设备重命名和路径收敛本身不难，难的是让上层不依赖瞬态名字——这点一旦忽略，故障时扩容或替换控制器就会卡住。
