根本原因是内核中device-mapper映射被进程、文件系统或LVM等持有引用；--force仅跳过用户态检查，不解除内核refcount>0导致的EBUSY。
为什么 dmsetup remove --force 仍报 “map in use”？
根本原因不是命令没加 --force，而是内核中该 device-mapper 映射仍被某个进程、文件系统或内核子系统（如 LVM、filesystem mount、open() fd）直接持有引用。强制删除只绕过用户空间检查，不解除内核级引用。
-
dmsetup remove --force会跳过设备是否“busy”的用户态判断，但若内核 refcount > 0，ioctl(DM_REMOVE)仍会返回EBUSY - 常见持有者：已挂载的文件系统（
mount | grep dm-）、LVM 逻辑卷（lvs -o +attr看是否处于 active 状态）、正在被dd/cat/数据库进程读写的块设备文件（lsof /dev/mapper/xxx） - 注意：
multipathd自身不会直接 hold map，但它触发的路径切换或重映射可能让底层 dm 设备被其他组件间接依赖
如何定位谁在占用这个 multipath map？
先确认 map 名称（如 mpatha），再逐层查依赖：
- 查挂载点：
findmnt -D /dev/mapper/mpatha或mount | grep mpatha - 查 LVM 使用：
pvs /dev/mapper/mpatha、lvs --all --options=+seg_pe_ranges | grep mpatha - 查打开的文件描述符：
lsof +D /dev/mapper/mpatha 2>/dev/null（需 root） - 查内核模块引用：
dmsetup info -c --noheadings mpatha | awk '{print $5}'输出非 0 表示 refcount > 0；再用dmsetup deps mpatha看下层设备是否也被占用
安全移除 multipath map 的实际步骤
不能跳过清理环节直接强删，否则可能引发 I/O hang 或内核 oops：
- 卸载所有相关挂载：
umount /dev/mapper/mpatha（若为 LVM LV，先lvchange -an vg/lv） - 停用 multipath 路径：
multipath -f mpatha（这会调用dmsetup remove并清理路径） - 若
multipath -f失败，再检查lsof和findmnt是否有遗漏；必要时重启依赖服务（如systemctl restart lvm2-lvmetad） - 最后执行：
dmsetup remove mpatha（不加--force，验证是否真空闲）；仅当确认无任何上层依赖且内核 refcount=0 后，才考虑dmsetup remove --force mpatha
dmsetup remove --force 的真实作用和风险
它只是把 device-mapper 表从内核中“标记删除”，但若仍有进程通过旧的 /dev/dm-X 或 /dev/mapper/xxx 发起 I/O，内核会 panic 或返回不可预测错误。
- 该 flag 不释放内存、不清理 bio、不通知上层驱动——它只是“假装删了”，适合调试或 recovery 场景
- 生产环境应避免使用；真正要删，必须确保：无 mount、无 LVM active、无 open fd、
dmsetup info mpatha中open字段为 0 - 如果
dmsetup remove持续失败，大概率是某个服务（如clvmd、corosync、数据库）仍在轮询设备，需结合strace -p $(pgrep multipathd)或systemctl status multipathd查日志
/dev/mapper/ 下的符号链接残留——它们不会出现在 lsof 里，但会让 dmsetup 认为设备 still in use。 
