共享存储挂载失败：dmsetup remove_all 与 Device-Mapper 残留映射排错指南

简介：这份资源聚焦 Linux 存储管理中的典型故障场景：同一存储设备挂载到两台服务器后，一台挂载成功、另一台却无法挂载或提示存储正忙。内容围绕 Device-Mapper 框架与 dmsetup 命令展开，适合有一定 Linux 基础、正在处理共享存储冲突的运维与后端开发人员参考。资源包共 1 个 docx 文档，约 11KB，篇幅精炼，便于快速查阅与收藏。文档从设备文件映射机制入手，分析多服务器同时访问同一存储时产生冲突的成因，并给出使用 dmsetup remove_all 清理映射后重新挂载的解决思路，同时延伸介绍快照、clone 与镜像等数据备份和冗余用法。已有 1648 人学习，可作为排查存储正忙、挂载失败问题的实用参考，帮助读者理解 dmsetup 在存储管理中的定位与常见操作路径。

1. 同一存储挂两台服务器，一台挂了另一台报“存储正忙”到底卡在哪

凌晨两点收到告警，一台业务服务器宕机重启后，另一台服务器上的共享存储目录突然变成只读，mount新挂载点直接甩回一句device is busy或者can't open blockdev。这种“同一个存储挂到两台服务器，挂了一台，另外一台无法挂载或者提示存储正忙”的故障，在双机热备、共享盘场景里几乎每个月都能碰到。折腾人的地方在于：存储本身没坏，网络也没断，但就是有一台机器死活挂不上，重启也不一定管用。如果你正在搜“存储正忙怎么解决”“dmsetup remove_all 报错”“多路径存储挂载失败”，这篇排错笔记就是按我踩过的坑一步步拆出来的，新手能照着命令跑通，熟手能看到 Device-Mapper 这一层的根因。

2. 先搞清“存储正忙”是谁在报错：从 mount 到 device-mapper 的链路

2.1 报错信息背后的三层结构

很多人一看到mount: /data: device is busy就以为是文件系统坏了，其实这条报错可能来自三个完全不同的层。第一层是 VFS 层，内核发现目标块设备已经被占用或者有未释放的引用；第二层是 Device-Mapper 层，dmsetup管理的映射设备还处于 active 状态，底层块设备被 hold 住；第三层是 SCSI/FC/iSCSI 层，存储端返回的 reservation 冲突或者路径状态异常。三层里任何一层没清理干净，表现都是“存储正忙”。

我一般会按这个顺序查：先lsblk看设备树，再dmsetup ls --tree看映射关系，最后multipath -ll看路径聚合状态。如果dmsetup ls里还有残留的mpathX或者dm-X设备，而底层/dev/sdX已经因为那台挂掉的服务器释放了，那基本就是 Device-Mapper 的映射表没同步。

2.2 为什么挂了一台服务器会连累另一台

共享存储挂两台服务器，常见做法是两边都跑多路径软件，各自维护一套 Device-Mapper 映射。正常情况各管各的，但存储端的 LUN reservation 是全局的。当 A 服务器异常宕机，它之前发起的 SCSI reservation 没有正常释放，存储控制器会认为这个 LUN 仍被 A 占用。B 服务器此时去mount，内核下发 IO 时被存储端拒绝，返回的 sense code 被上层翻译成“设备忙”或“输入/输出错误”。

更隐蔽的一种情况是 A 服务器虽然宕机了，但它的dm-multipath映射在 B 服务器的内核里还有残留引用。因为某些集群文件系统或者卷管理器会在启动时扫描所有可见 LUN，把还没清理的映射也加载进来。这时候 B 服务器上dmsetup ls能看到一个状态为ACTIVE但实际底层路径已经failed的映射设备，mount就会卡在这个死映射上。

2.3 用 dmsetup 定位残留映射的实操

先别急着remove_all，把现场留下来。执行下面这几条命令，把设备树和映射关系打出来：

# 查看块设备树，确认哪些设备还有挂载点 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # 查看 Device-Mapper 映射关系，重点看是否有残留的 mpath 设备 dmsetup ls --tree # 查看多路径聚合状态，确认路径是否全部 failed multipath -ll # 查看内核里谁在占用这个块设备 fuser -mv /dev/mapper/mpathX

lsblk的MOUNTPOINT列如果为空但设备还在，说明设备没挂载但映射还在。dmsetup ls --tree会显示mpathX (dm-X)这样的层级，如果底层(8:16)这类主次设备号对应的/dev/sdX已经不存在，那就是死映射。fuser -mv能直接告诉你哪个进程还占着这个设备，常见的是multipathd、lvmetad或者残留的mount进程。

提示：fuser -mv输出里的USER和PID列很关键，如果是multipathd占用，说明多路径守护进程还在轮询这个失效设备，需要先停服务再清理。

3. dmsetup remove_all 怎么用才不翻车：顺序、参数与失败回退

3.1 remove_all 的真实作用范围

dmsetup remove_all不是“删除所有存储设备”，它删除的是内核 Device-Mapper 里所有没有挂载点且没有打开引用的映射设备。如果某个dm-X设备上还有文件系统挂载，或者被 LVM、多路径守护进程 hold 住，这条命令会直接报Device or resource busy然后跳过。所以直接跑remove_all经常“看起来执行了但没效果”，因为真正卡住的那个设备根本没被删掉。

正确的做法是先卸载文件系统，再停掉持有引用的服务，最后才remove_all。顺序错了，命令白跑。

3.2 分步清理的完整命令序列

下面这套流程我在生产环境用过多次，核心思路是“先断上层引用，再清映射，最后重扫”：

# 1. 卸载所有挂载点，如果 umount 报 busy，用 lazy 卸载 umount /data 2>/dev/null || umount -l /data # 2. 停止多路径守护进程，避免它继续 hold 设备 systemctl stop multipathd # 3. 查看当前映射，确认哪些是残留的 dmsetup ls --tree # 4. 删除所有无引用的映射设备 dmsetup remove_all # 5. 如果 remove_all 报 busy，针对具体设备强制删除 dmsetup remove -f mpathX # 6. 重新扫描 SCSI 总线，让存储端重新上报 LUN echo "- - -" > /sys/class/scsi_host/host0/scan echo "- - -" > /sys/class/scsi_host/host1/scan # 7. 重启多路径服务，重建映射 systemctl start multipathd multipath -ll # 8. 重新挂载 mount /dev/mapper/mpathX /data

umount -l是 lazy 卸载，先断开目录树引用，等所有句柄释放后再真正卸载，适合有进程卡在存储 IO 上的场景。dmsetup remove -f是强制删除，只在你确认这个映射设备没有挂载、没有数据写入时用，强制删除后底层设备会重新暴露给上层。echo "- - -" > scan是让 SCSI 中间层重新扫描所有通道、目标、LUN，存储端如果已经释放了 reservation，这一步就能重新识别到设备。

3.3 remove_all 之后 mount 还是失败怎么办

如果remove_all执行完，dmsetup ls已经空了，但mount还是报can't read superblock或者wrong fs type，问题就不在 Device-Mapper 了。这时候要查两个地方：一是存储端的 LUN masking 或 zoning 是否还把 B 服务器排除在外，二是 B 服务器自己的multipath.conf里是否配置了reservation_key，导致重新挂载时又触发了 reservation 冲突。

我一般会先用dmesg -T | tail -50看内核最近关于sd、dm、multipath的日志。如果看到reservation conflict或者path failed，就去存储管理界面确认 LUN 的 host 映射列表里 A 服务器是否还在。有些存储阵列在 A 服务器宕机后不会自动清除它的 initiator 记录，需要手动移除或者等 reservation 超时。

注意：dmsetup remove_all不会删除 LVM 的物理卷标签，如果底层是 LVM，重新扫描后pvscan可能还会看到旧的 VG 信息，必要时用pvscan --cache刷新缓存。

4. 避坑：多路径存储挂载失败的 5 个常见问题

4.1 现象：remove_all 报 “Device or resource busy”，但 lsof 查不到进程

原因：multipathd或者lvmetad通过 netlink 持有设备引用，lsof和fuser不一定能显示。解决：先systemctl stop multipathd lvm2-lvmetad，再执行dmsetup remove_all。如果还不行，用dmsetup info -c mpathX看open count，非零就说明还有内核态引用。

4.2 现象：A 服务器重启后，B 服务器存储变只读

原因：A 服务器重启过程中重新扫描了 LUN，存储端把 reservation 又分配给了 A，B 的写入被拒绝，文件系统自动 remount 为只读。解决：在集群文件系统层面配置 fencing，或者在存储端设置 LUN 的reservation策略为ignore。临时恢复用mount -o remount,rw /data，但根本解决要改多路径配置。

4.3 现象：multipath -ll 显示路径全部 failed，但存储网络正常

原因：multipath.conf里的path_checker设置和存储类型不匹配，比如对某些全闪阵列用tur检查会误判。解决：改成path_checker readsector0或者path_checker directio，然后multipath -r重载配置。这个坑很玄学，同一套配置换一个存储型号就翻车。

4.4 现象：dmsetup remove_all 执行后设备名变了，脚本挂载失败

原因：重新扫描后多路径分配的mpathX编号可能变化，原来mpathb变成了mpatha。解决：不要用mpathX硬编码挂载，改用/dev/mapper/下的 WWID 别名，或者用multipath -ll里的uuid做 udev 规则绑定。

4.5 现象：umount -l 之后设备仍然 busy，remove_all 无效

原因：lazy 卸载只是断开目录树，如果有进程还在对已删除的文件句柄做 IO，内核不会释放块设备。解决：用fuser -mv /dev/mapper/mpathX找到 PID，确认业务可中断后kill -9，再执行dmsetup remove_all。生产环境慎用 kill，先确认没有未落盘数据。

5. 快速定位这类问题的排查习惯

遇到“存储正忙”别急着重启，我现在的固定动作是三步：第一步dmsetup ls --tree和multipath -ll同时打，确认是映射残留还是路径故障；第二步dmesg -T | grep -iE "reservation|dm-|multipath"看内核有没有 reservation conflict 记录；第三步fuser -mv确认用户态占用。这三步下来，90% 的情况能定位到是 Device-Mapper 层还是存储端的问题。

下面这张表是我整理的报错对照，贴在工位上随时查：

验证是否真正恢复，不要只看mount成功。我一般会再跑一次dd if=/dev/zero of=/data/testfile bs=1M count=10 oflag=direct，确认写入路径是通的，然后rm掉测试文件。如果dd报Input/output error，说明存储端还有残留 reservation，得回存储管理界面处理。

从那以后我每次处理共享存储挂载，都强制走一遍“停服务 → 清映射 → 重扫 → 重挂载”的流程，不再直接remove_all了事。希望帮到你。

本文还有配套的精品资源，点击获取