简介这份资源围绕 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 addressDevice-Mapper 映射残留但底层路径已断高第一类多半是本机问题lsof、fuser、mount就能定位第二类和第三类往往和“另一台服务器还占着”有关。很多人一看到“存储正忙”就直接dmsetup remove_all如果此时本机还有正常业务在跑这一刀下去会把正在使用的 DM 设备映射全删掉业务直接 IO 报错。所以顺序必须是先确认没有活跃业务再清残留。2.2 根因Device-Mapper 映射残留 文件系统日志未干净卸载Linux 访问块设备不是直接读写/dev/sdb中间通常隔着 Device-MapperDM层。多路径软件、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 总线让内核重新发现底层 LUNmultipath -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报Couldnt 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_allIO 直接报错现象执行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 -yxfs 用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偏文件系统 dirtyNo such device偏 DM 残留。归类决定后面走哪条路。第二步查占用与状态。mount | grep mapper、lsof /dev/mapper/*、fuser -m /挂载点、dmsetup info -c四条命令一起跑确认本机有没有活跃引用、DM 打开计数是否为零。第三步查另一端与文件系统。dumpe2fs -h看Filesystem state是否 cleanmultipath -ll看路径是否 activesg_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 bs1M count10 oflagdirect做一次直接 IO 测试确认链路和文件系统都正常最后删掉测试文件。从那以后我每次做双机存储切换前都强制走一遍“留档 → 确认 clean → 单边卸载 → 另一边清映射重扫 → 挂载后写测试”的流程再也没出现过两台来回抢盘的情况。希望帮到你。本文还有配套的精品资源点击获取