简介：这份资源围绕 Linux 存储管理中的典型故障展开，面向运维工程师、系统管理员及正在学习 Linux 存储机制的技术人员，重点解决同一存储设备挂载到两台服务器后，其中一台无法挂载或提示「存储正忙」的冲突问题。资源以 docx 文档形式呈现，压缩包内共 1 个文件，体积约 11KB，内容聚焦 dmsetup 命令与 Device-Mapper 框架的实战用法，涵盖设备映射关系查看、remove_all 清理、重新挂载等关键操作思路。读者可从中理解多服务器共享存储时冲突产生的底层原因，掌握用 dmsetup 删除映射、恢复挂载的排错路径，并延伸了解快照、clone、镜像等数据备份与冗余手段。目前已有 1648 人学习下载，适合需要快速定位存储挂载异常、补充 Linux 存储管理技能的中高级运维人员参考。
1. 存储正忙挂载失败：两台服务器抢同一块盘，为什么总在第二台翻车
“mount: /data: 存储正忙”或者干脆wrong fs type, bad option, bad superblock——如果你在两台 Linux 服务器上挂同一块共享存储，十有八九见过这类报错。更气人的是：A 服务器挂得好好的，B 服务器一执行 mount 就失败；把 A 上的挂载卸掉，B 立刻就能挂上。看起来像玄学，其实是 Linux 存储栈里一个非常经典的冲突：同一块底层设备被两个内核同时认领，Device-Mapper 层残留了映射，或者文件系统日志没干净卸载，第二台机器就会撞上“设备正忙”或“超级块不可读”。
这类故障在双机热备、共享 SAN、虚拟化宿主机、数据库主备切换场景里高频出现。新手看到“存储正忙”第一反应是重启，重启完发现还是挂不上；熟手会先查dmsetup、multipath、lsof和mount的残留状态。这篇笔记就按“报错现象 → 根因定位 → 可抄作业的解决命令 → 避坑清单 → 快速排查套路”走一遍，核心解决动作只有一条命令：dmsetup remove_all，但什么时候能用、用了之后要补什么，才是真正不翻车的关键。
2. 存储正忙报错拆解：从 mount 失败到 dmsetup 残留映射
2.1 先分清三种“挂不上”的报错，别一上来就 remove_all
同一个存储挂两台服务器，报错并不是只有一种。我一般先按报错文本分三类，因为不同类别的根因和处置顺序完全不同：
| 报错文本 | 典型含义 | 危险等级 |
|---|---|---|
mount: /data: 存储正忙/device is busy | 本机已有进程或挂载点占用，或 DM 层设备被引用 | 中 |
wrong fs type, bad option, bad superblock | 文件系统超级块不可读，常见于另一端未干净卸载 | 高 |
cannot open /dev/mapper/xxx: No such device or address | Device-Mapper 映射残留但底层路径已断 | 高 |
第一类多半是本机问题，lsof、fuser、mount就能定位；第二类和第三类往往和“另一台服务器还占着”有关。很多人一看到“存储正忙”就直接dmsetup remove_all，如果此时本机还有正常业务在跑，这一刀下去会把正在使用的 DM 设备映射全删掉，业务直接 IO 报错。所以顺序必须是：先确认没有活跃业务，再清残留。
2.2 根因：Device-Mapper 映射残留 + 文件系统日志未干净卸载
Linux 访问块设备不是直接读写/dev/sdb，中间通常隔着 Device-Mapper（DM）层。多路径软件、LVM、加密盘、快照都会在 DM 层注册映射，/dev/mapper/下那些设备就是映射出来的。当一台服务器异常宕机、强制下电、或者存储链路闪断，DM 映射不会自动消失，内核里还留着“这块设备归我管”的状态。
此时第二台服务器去挂同一块底层 LUN，会遇到两个问题：一是底层设备被第一台的残留映射“逻辑占用”，二是文件系统如果没走正常umount，日志区（journal）处于 dirty 状态，第二台挂载时校验超级块直接失败。dmsetup remove_all解决的是第一个问题——把本机所有 DM 映射清空，让内核重新识别底层设备；但它不解决文件系统 dirty，所以清完映射后如果还报超级块错误，就得走fsck或回到原服务器干净卸载。
提示：
dmsetup remove_all是“清空本机所有 DM 映射”，不是“只清某一块盘”。执行前必须确认本机没有正在使用的 LVM、多路径或加密卷。
2.3 解决动作：确认无业务后执行 dmsetup remove_all 并重新识别
标准处置流程如下，每一步都有它的道理，别跳步：
# 1. 确认本机没有活跃挂载和占用进程 mount | grep -E 'mapper|data' lsof /dev/mapper/* 2>/dev/null fuser -m /data 2>/dev/null # 2. 卸载所有相关挂载点（能正常 umount 最好，不行再考虑强制） umount /data # 3. 查看当前 DM 映射，做到心里有数 dmsetup ls --tree dmsetup info -c # 4. 清空所有 DM 映射（确认无业务后执行） dmsetup remove_all # 5. 让内核重新扫描 SCSI 设备与多路径 rescan-scsi-bus.sh multipath -r # 6. 重新挂载 mount /dev/mapper/mpathX /datadmsetup remove_all的作用是遍历内核中所有 DM 设备并逐个删除映射，等价于把 DM 层“归零”。rescan-scsi-bus.sh重新扫描 SCSI 总线，让内核重新发现底层 LUN；multipath -r重新加载多路径配置并重建/dev/mapper/mpathX。顺序不能反：先删映射再重扫，否则重扫出来的设备还是挂在旧映射上。
如果第 6 步仍然报超级块错误，说明文件系统层面没恢复，需要先确认另一端已彻底卸载，再对本机设备执行fsck -y /dev/mapper/mpathX。fsck有风险，务必确认没有第二台机器在写这块盘。
2.4 参数与命令说明：remove_all 到底删了什么
dmsetup remove_all没有交互确认，执行即生效。它删除的是内核 DM 表中的所有 mapped device，包括 LVM 的vg-lv、多路径的mpathX、加密的cryptX。删除后/dev/mapper/下的节点会消失，直到你重新激活（vgchange -ay）或重扫多路径。
dmsetup ls --tree用树形展示映射依赖关系，能看出哪个 mpath 下面挂着哪个底层 sd 设备；dmsetup info -c用列格式输出所有 DM 设备的状态、打开计数。打开计数（open count）不为 0 说明还有引用，此时remove_all可能删不干净或报Device or resource busy。所以第 1 步的lsof、fuser不是走过场，是判断能不能安全清映射的依据。
3. 双机共享存储冲突排查：谁在占盘、日志是否干净、映射是否残留
3.1 判断“另一台是否真的释放了”：从锁和日志两头查
双机场景最怕的是“我以为它卸载了”。判断另一端是否释放，不能只靠对方口头说，要看两个硬证据：一是文件系统日志是否干净，二是存储侧是否还有该主机的注册/预留。常见做法是在能挂载的那台机器上先umount，然后：
# 查看文件系统是否标记为 clean dumpe2fs -h /dev/mapper/mpathX 2>/dev/null | grep -i state # 输出 Filesystem state: clean 才算干净 # 查看是否有残留的挂载记录 cat /proc/mounts | grep mpathX # 查看 SCSI 设备是否有预留冲突（部分存储支持） sg_persist --in --read-keys /dev/sdXFilesystem state: clean是关键信号。如果是not clean或with errors，说明上一次没正常卸载，第二台挂载必然失败。此时要么回到原服务器重新挂载再干净卸载，要么在确认无写入的前提下fsck。sg_persist用于查 SCSI 预留，某些共享存储会用 persistent reservation 防止双写，如果预留没释放，第二台会被存储侧直接拒绝。
3.2 多路径与 LVM 叠加时的排查顺序
很多环境是“多路径 + LVM”两层叠加，报错会更绕。排查顺序建议从下往上：
# 底层：物理链路与 SCSI 设备 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT multipath -ll # 中层：DM 映射 dmsetup ls --tree # 上层：LVM 与文件系统 pvs; vgs; lvs blkid /dev/mapper/vg-lvmultipath -ll能看出每条路径的状态是active还是failed，如果路径全 failed，说明存储链路本身有问题，这时候清 DM 映射没用，得先修链路。dmsetup ls --tree看映射依赖，pvs/vgs/lvs看 LVM 是否还能识别 PV。如果pvs报Couldn't find device，说明 PV 对应的 DM 设备没了，需要vgchange -ay重新激活，而不是盲目remove_all。
3.3 强制卸载与安全卸载的边界
umount -f和umount -l是两把双刃剑。-f强制卸载，适合 NFS 等网络文件系统；-l延迟卸载，把挂载点从命名空间摘掉但等引用归零才真正释放。对本地块设备上的 ext4/xfs，强制卸载可能让日志更脏。我的习惯是：能正常umount就正常卸；卸不掉先fuser -m找进程，杀进程再卸；实在不行才umount -l，并且之后一定补一次fsck检查。
注意：在共享存储上，任何一台机器的强制卸载或强制下电，都可能让另一台无法挂载。双机切换前，标准动作是先在主用机
umount，确认Filesystem state: clean，再在备用机挂载。
4. 避坑与常见问题：remove_all 用错场景的血泪记录
4.1 坑一：业务还在跑就执行 remove_all，IO 直接报错
现象：执行dmsetup remove_all后，本机数据库进程大量Input/output error，/dev/mapper/下设备消失。 原因：DM 映射被删，上层文件系统失去底层设备，所有未落盘的 IO 失败。 解决：执行前必须mount | grep mapper、lsof /dev/mapper/*、fuser -m三连确认无占用。生产环境优先在维护窗口做，别在业务高峰清映射。
4.2 坑二：只清了一台，另一台没清，来回抢盘
现象：A 机remove_all后能挂了，过一会 B 机又报存储正忙，两边反复。 原因：双机都残留 DM 映射，谁先重扫谁先占，另一方再挂就冲突。 解决：双机切换要成对操作——主用机先umount并确认 clean，再在备用机清映射、重扫、挂载。不要两台同时执行remove_all后一起挂。
4.3 坑三：把 remove_all 当万能药，忽略文件系统 dirty
现象：清完映射重新挂载，仍报bad superblock或Structure needs cleaning。 原因：remove_all只清 DM 层，不修文件系统日志。 解决：确认无第二台写入后，对设备执行fsck -y；xfs 用xfs_repair。修复前先做只读检查，别直接-y上生产。
4.4 坑四：多路径没重扫，映射删了设备也回不来
现象：remove_all后/dev/mapper/mpathX一直不出现，multipath -ll为空。 原因：只删了 DM 映射，没让多路径重新聚合底层路径。 解决：补multipath -r或重启multipathd，必要时rescan-scsi-bus.sh重扫总线。顺序是删映射 → 重扫总线 → 重载多路径。
4.5 坑五：没记录原始映射，删完不知道怎么恢复
现象：清完映射后不记得原来 LVM 的 LV 名和挂载点，恢复靠猜。 原因：执行前没留档。 解决：动手前先dmsetup ls --tree > /tmp/dm_before.txt、mount > /tmp/mount_before.txt、multipath -ll > /tmp/mpath_before.txt。有档可查，恢复不慌。
5. 快速定位这类问题的排查套路与验证方法
遇到“同一存储挂两台、一台挂了另一台挂不上”，我现在的固定套路是四步，顺序不乱：
第一步，看报错文本归类。存储正忙偏本机占用，bad superblock偏文件系统 dirty，No such device偏 DM 残留。归类决定后面走哪条路。
第二步，查占用与状态。mount | grep mapper、lsof /dev/mapper/*、fuser -m /挂载点、dmsetup info -c四条命令一起跑，确认本机有没有活跃引用、DM 打开计数是否为零。
第三步，查另一端与文件系统。dumpe2fs -h看Filesystem state是否 clean，multipath -ll看路径是否 active，sg_persist看预留是否释放。这一步是判断“能不能安全清映射”的依据。
第四步，按序处置并验证。确认无业务后umount→dmsetup remove_all→rescan-scsi-bus.sh→multipath -r→mount。挂载成功后用df -h、blkid、mount | grep三重确认，再让业务侧做一次读写抽检。
验证是否真正恢复，不能只看 mount 成功。我一般会touch /data/.health_check && rm /data/.health_check做一次写测试，再dd if=/dev/zero of=/data/.dd_test bs=1M count=10 oflag=direct做一次直接 IO 测试，确认链路和文件系统都正常，最后删掉测试文件。
从那以后，我每次做双机存储切换前，都强制走一遍“留档 → 确认 clean → 单边卸载 → 另一边清映射重扫 → 挂载后写测试”的流程，再也没出现过两台来回抢盘的情况。希望帮到你。
本文还有配套的精品资源，点击获取
