“device busy”根本原因是device-mapper依赖未清，非进程占用；需用dmsetup ls --tree查真实dm名，dmsetup deps确认无依赖，再dmsetup remove --noudevsync逐级删除。
为什么 multipath -f 报 “device busy”？
根本原因不是设备真被进程占着，而是内核中 device-mapper 的依赖关系没清理干净。比如某个 multipath 设备（如 mpatha）底下还有正在使用的 logical volume、LVM snapshot、或挂载点残留（哪怕 umount 看似成功，dmsetup deps 仍可能显示非零依赖）。multipath -f 是软删除，会检查依赖并拒绝操作；它不等同于直接删 device-mapper table。
dmsetup remove 强制删 multipath 设备的正确顺序
不能直接对 multipath 设备名（如 mpatha）执行 dmsetup remove——它通常是个“映射器”，底层是类似 360050768028201d90000000000000001 这样的 WWID 映射名。必须先查清真实 dm 名，再逐级清理：
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 用
dmsetup ls --tree找出 multipath 设备对应的底层 dm name（常为mpath-xxx或360050768...格式） - 确认无活跃依赖：
dmsetup deps -o devname <dm-name>输出应为空或仅含底层物理路径（如sda） - 停用前加
--noudevsync避免 udev 触发重载：dmsetup remove --noudevsync <dm-name> - 若报 “device is busy”，说明仍有 open count > 0，用
lsof +D /dev/mapper/或lsof /dev/dm-X找残留 fd，或检查/proc/mounts是否漏掉 bind mount 或 namespace 挂载
绕过 multipathd 自动恢复的临时屏蔽方法
即使删掉了 dm 设备，multipathd 可能几秒内自动重建——尤其当底层路径（如 /dev/sda）仍在线。临时禁用自动重映射：
- 停服务：
systemctl stop multipathd（注意：生产环境慎用） - 或临时屏蔽规则：在
/etc/multipath.conf中添加blacklist { devnode "^mpath.*" }并multipathd reconfigure - 删完后若需恢复，记得
systemctl start multipathd并multipath -v2重新发现
常见误操作与后果
直接对 /dev/mapper/mpatha 执行 dmsetup remove mpatha 多数会失败，因为该名字只是 symlink，真实 dm name 是 mpath-xxx；更危险的是跳过 dmsetup deps 检查就强删，可能导致 LVM VG 无法激活、或后续 pvscan 报 “duplicate PV” 错误。另外，dmsetup remove --force 在较新内核（5.4+）已弃用，强制使用会报错，必须用 --noudevsync 替代。
