当 multipathd 显示“map in use”却无进程占用时，本质是内核 device-mapper refcount > 0；应先确认无挂载、LVM、fd 占用，再通过 multipath -r/-f 或重启 multipathd 优雅清理；仅在万不得已时用 dmsetup remove --force --nolockfs --retry 强制移除。
当 multipathd 显示某 multipath map 为 “map in use”，而你又确认没有进程在使用该设备（如未挂载、未被 LVM 使用、无 open fd），但仍无法通过 dmsetup remove 删除，本质是 device-mapper 内核中该映射仍被持有引用（refcount > 0）。强制删除需谨慎操作，以下为安全、有效的处理步骤：
确认 map 确实无用户态占用
先排除常见误判：
- 检查是否被挂载：
findmnt -D /dev/mapper/xxx或mount | grep xxx - 检查是否属于 LVM PV：
pvs | grep xxx，若存在，先vgchange -an停用卷组 - 检查是否有进程打开底层块设备：
lsof +D /dev/dm-* | grep xxx（注意：lsof 对 dm 设备支持有限，更可靠的是ls -l /proc/*/fd/ 2>/dev/null | grep xxx） - 检查是否被其他 multipath map 依赖（如 alias 指向同一 wwid）：
multipath -ll查看 map 关系
通知 multipathd 主动清理
不要跳过这步直接硬删。让 multipathd 主动释放是首选：
- 尝试刷新 multipath 配置：
multipath -r（重载路径，可能触发自动清理） - 如果 map 已失效或路径全 down，可先
multipath -f强制 flush（注意：-f 不等于 -F，它会尝试优雅移除） - 若仍卡住，重启 multipathd：
systemctl restart multipathd（多数情况下会清空 stale map）
强制清除 device-mapper refcount（仅限确认无业务影响）
若上述无效且确定无任何 I/O 或用户态依赖，可手动降低内核 refcount：
- 查看当前 refcount：
dmsetup info -c | grep，第三列即 open count - 强制释放（绕过 refcount 检查）：
dmsetup remove --force --nolockfs - 若提示 “device is busy”，再加
--retry参数重试：dmsetup remove --force --nolockfs --retry - 极端情况（如 refcount 卡死在 1）：可尝试
echo 1 > /sys/block/dm-X/device/delete（X 为对应 dm 号，需从ls -l /sys/block/ | grep查得），但此操作风险高，仅限调试环境
预防后续再次出现
“map in use” 常源于异常退出或路径震荡未清理干净：
- 确保 multipath.conf 中配置
flush_on_last_del yes（默认开启，确保最后一个路径删除时 flush map） - 避免手动 kill multipathd，应使用 systemctl 控制
- 在存储链路不稳定时，禁用
queue_if_no_path或调大no_path_retry，减少 map 频繁重建 - 定期运行
multipath -v3 -d查看 debug 日志，定位残留 map 成因
不复杂但容易忽略的是：multipathd 的 map 生命周期管理依赖 udev 事件和内核通知，一旦事件丢失或延迟，refcount 就可能滞留。所以优先走 multipathd 自身的 flush 流程，而非直击 dmsetup。
