简介这份资源聚焦 Linux 存储管理中的典型故障场景同一存储设备挂载到两台服务器后一台挂载成功、另一台却无法挂载或提示存储正忙。内容围绕 Device-Mapper 框架与 dmsetup 命令展开适合有一定 Linux 基础、正在处理共享存储冲突的运维与后端开发人员参考。资源包共 1 个 docx 文档约 11KB篇幅精炼便于快速查阅与收藏。文档从设备文件映射机制入手分析多服务器同时访问同一存储时产生冲突的成因并给出使用 dmsetup remove_all 清理映射后重新挂载的解决思路同时延伸介绍快照、clone 与镜像等数据备份和冗余用法。已有 1648 人学习可作为排查存储正忙、挂载失败问题的实用参考帮助读者理解 dmsetup 在存储管理中的定位与常见操作路径。1. 同一存储挂两台服务器一台挂了另一台报“存储正忙”到底卡在哪凌晨两点收到告警一台业务服务器宕机重启后另一台服务器上的共享存储目录突然变成只读mount新挂载点直接甩回一句device is busy或者cant 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/mpathXlsblk的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 /dataumount -l是 lazy 卸载先断开目录树引用等所有句柄释放后再真正卸载适合有进程卡在存储 IO 上的场景。dmsetup remove -f是强制删除只在你确认这个映射设备没有挂载、没有数据写入时用强制删除后底层设备会重新暴露给上层。echo - - - scan是让 SCSI 中间层重新扫描所有通道、目标、LUN存储端如果已经释放了 reservation这一步就能重新识别到设备。3.3 remove_all 之后 mount 还是失败怎么办如果remove_all执行完dmsetup ls已经空了但mount还是报cant 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 又分配给了 AB 的写入被拒绝文件系统自动 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 之后设备仍然 busyremove_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 层还是存储端的问题。下面这张表是我整理的报错对照贴在工位上随时查报错信息最可能层级首选命令后续动作device is busyDevice-Mapper 残留dmsetup ls --tree停 multipathd 后 remove_allcant read superblock存储端 reservationdmesg -T | grep reservation检查 LUN maskingpath failed多路径配置multipath -ll改 path_checker 后重载wrong fs type文件系统未识别blkid /dev/mapper/mpathX确认是否需重新 mkfsinput/output error底层链路lsblkdmesg查 FC/iSCSI 链路状态验证是否真正恢复不要只看mount成功。我一般会再跑一次dd if/dev/zero of/data/testfile bs1M count10 oflagdirect确认写入路径是通的然后rm掉测试文件。如果dd报Input/output error说明存储端还有残留 reservation得回存储管理界面处理。从那以后我每次处理共享存储挂载都强制走一遍“停服务 → 清映射 → 重扫 → 重挂载”的流程不再直接remove_all了事。希望帮到你。本文还有配套的精品资源点击获取