银河麒麟V10运维：磁盘卸载、删除LVM与配置清理实战

1. 动手之前先想清楚这活儿到底在解决什么问题银河麒麟v10 服务器上做磁盘卸载、删除 LVM、清理配置文件听起来像是三件独立的事但在实际运维里它们往往是一条链上的三个动作。我手上这批机器最早是按 LVM 铺的盘逻辑卷一路铺到业务目录后来存储架构调整几块数据盘要下线转做备份存储池于是就有了这轮卸载磁盘、删除 LVM、清理配置文件的操作。做完之后我把过程和踩过的坑整理了一遍因为这套流程看着基础真到生产环境里光是 umount 卡住这一项就能耗掉半下午。先把范围说清楚这里讲的是数据盘的下线与回收也就是把一块或一组已经用 LVM 管理、已经被挂载使用的磁盘从操作系统层面干净地摘出去——取消挂载、拆掉逻辑卷、删掉卷组和物理卷、擦除磁盘上的残留签名、再把指向它的配置文件条目清理干净。它的反向操作是加盘扩容这个大家都会但撤盘在文档里往往只有寥寥几行命令实际执行时的顺序、确认动作和善后工作才是真正决定成败的地方。适合谁看如果你是刚开始接手银河麒麟v10 服务器运维的同学这篇可以当成一份可以照抄的操作清单如果你已经做过不少次磁盘上下线里面关于 LVM 元数据备份、多路径残留、fstab 里 nofail 参数这些细节应该也能补上你经验里的几个盲点。需要提前说明的是银河麒麟高级服务器操作系统 v10 在用户态上与主流 RHEL 系发行版的操作习惯基本一致命令、目录布局、服务管理方式都相通所以这套方法在同类 Linux 服务器上同样能套用。整篇内容我会按判断场景 → 认清结构 → 卸载 → 拆 LVM → 清配置 → 排错这个顺序来写每一步都会讲清楚为什么这么做而不只是给一条命令。因为磁盘操作最怕的就是照着敲但不知道后果删错一层代价可能是几小时的恢复时间。2. 认清 LVM 的三层结构删之前得知道自己删的是什么2.1 PV、VG、LV 的关系用盖楼来理解LVM 这套东西如果只记命令会很容易搞混我习惯用盖楼来类比。物理卷 PV就是一块地皮通常是整块硬盘或者一个分区比如 /dev/sdb、/dev/sdb1它是 LVM 最底层的原料。卷组 VG是把若干块地皮圈起来的院子地皮进了院子就不再属于某一栋楼而是统一分配所以一个 VG 可以由多个 PV 组成。逻辑卷 LV就是在院子里盖起来的一栋栋楼业务看到的是 LV比如 /dev/vg_data/lv_app它背后可能横跨了院子里好几块地皮。这个类比最关键的一点是地皮可以单独退楼必须先拆。因为 LV 可能横跨多个 PV你直接把某块地皮抽走上面盖着的楼就直接塌了。所以删除顺序永远是反着来的先拆楼LV再拆院子VG最后才能退地皮PV。很多人第一次上手会把 pvremove 当成第一步结果系统直接报 PV is still in use by VG白折腾一圈。每一层的删除颗粒度也不一样。删 LV 是精确操作你指定哪个逻辑卷就删哪个其他逻辑卷不受影响。删 VG 是整体操作这个卷组下所有的 LV 都得先清空或者一起删。删 PV 则要求这个物理卷已经不属于任何 VG否则 LVM 会拒绝执行——这个拒绝其实是保护机制别想着用 -ff 强行绕过。2.2 银河麒麟v10 下的设备命名习惯银河麒麟v10 里磁盘设备的命名遵循内核的通用规则本地 SATA/SAS 盘一般是 /dev/sda、/dev/sdb 这种NVMe 盘是 /dev/nvme0n1、/dev/nvme1n1。这里有个坑sda、sdb 这种名字是按探测顺序分配的热插拔或者换槽位之后编号可能变。所以真正做盘下线的时候绝不能只靠 /dev/sdX 来判断是不是目标盘必须结合容量、序列号、挂载点一起确认。LVM 创建出来的设备节点在 /dev/mapper/ 和 /dev/vg_name/ 两个位置都能看到指向的是同一组 dm- 设备。比如 VG 叫 vg_data、LV 叫 lv_app那 /dev/mapper/vg_data-lv_app 和 /dev/vg_data/lv_app 是等价的实际对应的块设备是 /dev/dm-0、/dev/dm-1 这种。lsblk 输出里会看到 dm 设备挂在 sd 设备下面形成树状结构这个树状关系就是判断依赖的核心依据。多路径环境还要多一层。如果服务器接了存储阵列磁盘会以 dm-multipath 的形式出现路径名可能是 /dev/mapper/mpatha 或者 WWID 长串lsblk 里会显示成 mpath 类型的父节点底下再挂 LVM。这种环境下删盘要先把多路径层停掉否则你删完 LVM多路径缓存里还留着残留映射重启后可能出现幽灵设备。2.3 用四条命令建立全局视图动手之前先花两分钟把全貌看一遍。我固定用这四条命令组合侦察基本上能把结构、容量、挂载关系一次性看全lsblk -f -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,UUID pvs -opv_used,pv_free vgs -ovg_free,lv_count,pv_count lvs -olv_size,seg_count,segtype,lv_attrlsblk 的-f会带出文件系统类型和 UUID这个 UUID 后面清理 fstab 时要用到先记下来。pvs/vgs/lvs 这三个命令输出非常紧凑建议加上-o扩展字段能直接看到 PV 已用/剩余、VG 里有多少 LV 和 PV、LV 的分段类型。特别要留意 lv_attr 这个属性列第一位的字母代表卷类型t是 thin poolV是 thin volumes是快照o是 origin-是普通线性卷。删的时候 thin 和快照都得先处理顺序错了会报错。提示建议在操作前把vgs、lvs、pvs的完整输出和lsblk -f的结果一起存成文本文件留档命名带上日期。这个动作只要十秒钟但在出问题时是救命稻草。还有一个必看的cat /proc/mounts或者findmnt。lsblk 显示的挂载点有时候不够全特别是 bind mount 和容器里的挂载。findmnt 输出的树状结构更清晰能直接看到哪个设备挂在哪个目录、用什么参数挂的排查 umount 失败时特别好用。3. 卸载磁盘实操umount 卡住了怎么办3.1 先确认这块盘到底有没有人用umount 报 target is busy 的时候别急着上-f或者-l先查是谁占着。这一步很多人跳过结果是强制卸载之后进程继续往已经消失的挂载点上写数据文件句柄还在数据直接丢日志里全是 I/O error。查占用有三个层次。第一个是lsof D /mnt/data按目录递归查进程缺点是目录大的时候慢。第二个是fuser -muv /mnt/data直接按挂载点查输出简练我个人更常用这个。第三个是lsof /mnt/data只查直接打开的文件配合grep快速定位。三个命令的结果可以互相印证用哪个都行关键是要看到底是哪个进程、哪个 PID。findmnt /mnt/data fuser -muv /mnt/data lsof D /mnt/data 2/dev/null | head -30如果查出来是业务进程那就要走正常流程停服务、确认业务侧没有写入、再卸载。如果是 shell 自身的当前目录在挂载点里那就cd /先退出来——这个情况特别常见而且特别容易被忽略因为提示信息只说 busy不告诉你是哪个 shell。3.2 umount 失败的六种典型情况和处理我把实际遇到过的 umount 失败原因整理成了一张表按出现频率排的现象/报错根本原因处理方式风险等级target is busy有进程打开文件或 cwd 在挂载点fuser/lsof 定位后停服务低device is busy挂载点被 bind mount 引用先卸子挂载点再卸父中umount: /mnt/data: not mounted实际挂载点路径不对findmnt 确认真实挂载点低一直卡住不返回NFS/存储链路异常检查链路谨慎用 -f高报 device busy 但查不到进程内核模块占用或 deferred IOsync 后重试必要时 lazy中卸载后进程仍报错强制卸载导致句柄失效重启相关服务中关于umount -llazy和umount -fforce我的态度是能不用就不用。-l是把挂载点从命名空间里摘掉但内核里实际还挂着等所有引用释放后才真正卸载看起来命令立刻返回了实际上数据可能还在写。-f主要用于无响应的网络文件系统本地盘用它基本等于放弃了数据一致性检查。真要动这两个参数前提是先sync三遍并且确认业务已经彻底停止。3.3 swap 分区也要走卸载这一步如果这块盘上有 swap 逻辑卷光 umount 是没用的得先 swapoff。检查当前 swap 用cat /proc/swaps或者swapon --show找到目标后执行swapoff /dev/vg_data/lv_swap。swapoff 会触发内存页回迁如果 swap 里存了几 GB 数据这一步可能耗时几十秒甚至几分钟命令会看起来像卡住了别急着 CtrlC。回迁期间系统内存占用会上升所以如果当前内存本来就紧张最好挑业务低谷期做或者先把不重要的服务停掉腾出内存。swapoff 完成后再执行 umount顺序不能反。我见过有人先 umount 再 swapoff结果 umount 直接报 busy——因为 swap 在跑挂载点当然释放不了。swapoff 不只是性能问题还涉及数据安全。如果 swap 里存过敏感内容处理完这块盘之后磁盘擦除那一步要做得彻底一些不能只清文件系统头部。3.4 卸载完成后的确认动作umount 返回 0 不代表就干净了还要再确认三件事。第一findmnt里已经看不到这个挂载点第二df -h里对应条目消失第三dmesg -T | tail -30里没有该设备的 I/O 报错。这三个都过了才算卸载真的完成。顺手做一次sync把页缓存里的脏页刷下去。这个动作在删除 LVM 之前特别重要因为 lvremove 只关心 LVM 元数据不负责帮你刷文件系统缓存缓存里有数据的话可能造成元数据与数据不一致。做完确认再进入删除 LVM 的环节。4. 删除 LVM从 LV 到 PV 逐层拆解4.1 先停用还是先删顺序和两种做法LVM 的删除有两种做法。一种是直接lvremoveLVM 会自动帮你处理停用另一种是先vgchange -an vg把整个卷组停用再删。日常单机环境直接 lvremove 就够了但在共享存储或者集群环境里必须先vgchange -an释放锁否则删除操作会被 lock 挡住。停用这一步在排查问题时也很有用。lvchange -an /dev/vg_data/lv_app会断开设备映射让系统看不见这个逻辑卷但元数据还在随时能-ay激活回来。这是个无损的中间态可以拿来做验证停用后如果没有任何服务报错说明确实没人在用如果有服务立刻报错那说明还有依赖没理清。删 LV 之前先看一眼它的分段情况。lvs -osegtype,seg_count,devices能看到这个 LV 是 linear、striped 还是 thin。thin pool 要特别注意必须先删掉所有 thin volume最后才能删 thin pool 本身反过来做会报 thin pool is in use。快照同理先删快照再删 origin。4.2 删除逻辑卷确认提示别乱按 y命令本身很直接lvremove /dev/vg_data/lv_app # 或者按路径 lvremove vg_data/lv_app # 批量删除某个 VG 下的所有 LV谨慎 lvremove -f vg_data不指定具体 LV 而只给 VG 名LVM 会把该 VG 下所有 LV 列出来问你要不要删。这个交互提示一定要一行一行看别看到 y/n 就下意识回车。我曾经见过误删的案例操作者以为只删一个 LV实际上命令敲成了整个 VG提示里列了七八个卷他还没看清就确认了结果系统盘上的根卷也在里面。如果 LV 上还有数据且你不确定是否有人用先用lvchange -an停用观察一段时间业务有没有异常再删。这个停用观察法在不确定性的场景里非常值钱。删完之后lvs确认一下列表里已经没有目标卷了。然后再看vgsVG 的 Free Size 应该相应增加。如果 Free Size 没变说明 LV 没删干净或者有快照占着。4.3 删除卷组和物理卷LV 清空之后VG 里应该只剩元数据了。删 VGvgremove vg_data如果 VG 里还有残留 LVvgremove 会拒绝并提示。这时候回到上一步继续清理别用-f强推。vgremove 完成后再看pvs对应 PV 的 VG 字段应该变成空。最后删 PVpvremove /dev/sdb1pvremove做的事情是把磁盘头部的 LVM 标签label和元数据区清掉让它从LVM 物理卷退化成一块普通分区。执行完之后用pvs确认已经不列这个设备了如果还列着说明标签没清干净可以用pvremove -ff -y /dev/sdb1再试一次但更强硬的清理方式其实是直接擦除磁盘签名这个下面单独讲。注意pvremove 只能作用于已经不归属任何 VG 的 PV。如果报 PV is still in use意思就是 VG 还没删干净回到 4.3 往前一步排查。4.4 擦除磁盘签名wipefs、dd、blkdiscard 怎么选LVM 标签删了但分区表、文件系统超级块、旧签名可能还留在盘上。这些残留的危害在于机器重启后LVM 扫描可能又把这块盘认出来lsblk -f里显示一个没有挂载点但有 UUID 的幽灵设备甚至自动激活成卷组。所以下线盘的最后一步必须是擦除签名。三种方式适用场景不同我做了个对比方式命令示例作用范围速度适用场景wipefswipefs -a /dev/sdb清除已知签名含 LVM、分区表秒级首选安全可控dd 清零头部dd if/dev/zero of/dev/sdb bs1M count100前 100MB 全零秒级需要彻底清引导区和元数据blkdiscardblkdiscard -f /dev/sdb整盘 TRIM秒级到分钟SSD/NVMe需确认盘支持我的习惯顺序是先wipefs -a /dev/sdb再用wipefs -a /dev/sdb1把每个分区也清一遍如果分区还在然后partprobe /dev/sdb让内核重读。如果这块盘要转给别的系统用或者盘上有过敏感数据再加一步 dd 清头部。对于 SSDblkdiscard是最彻底的它会触发闪存块的擦除比 dd 快得多也不会产生大量写入。但要注意两点一是必须用-f显式确认二是划走一块盘之前得确认盘上没有你还需要的东西——blkdiscard 不可逆。还有虚拟化环境下的虚拟磁盘有时不支持 discard会直接报错那就退回 wipefs dd。擦除完再lsblk -f看一眼目标盘应该是干净的、没有 FSTYPE 和 UUID 的状态。到这一步磁盘层面的事情就做完了。5. 清理配置文件把记忆也一并抹掉5.1 /etc/fstab 的清理和 nofail 参数磁盘删了但 fstab 没清后果是下次重启系统进不去——因为 fstab 里写的挂载项找不到设备默认行为是启动卡住等待或者直接丢进紧急模式。这个坑我踩过一次半夜重启一台测试机结果它卡在 emergency mode第二天才想起来 fstab 里那条遗留记录。清理方式很简单就是把对应行删掉或者注释掉。但这里有个技巧值得说临时保留观察期。如果你不确定这块盘是否真的不再需要可以先把 fstab 里那一行的挂载参数后面加上nofail和x-systemd.device-timeout5这样设备不在时系统也能正常启动只是这个挂载点空着。观察一两周确认没人用再彻底删掉这一行。# 修改前先备份 cp /etc/fstab /etc/fstab.bak.$(date %F) # 查看当前内容找到目标行 grep -n vg_data\|/mnt/data /etc/fstab改完之后一定要验证systemctl daemon-reload让 systemd 重读然后mount -a试一遍。如果 mount -a 没有报错说明剩下的配置都是自洽的。千万不要在改完 fstab 后直接重启来验证先用 mount -a 检查出问题还能当场改回来。fstab 的字段含义也顺带过一遍方便你判断哪些行受影响第一列是设备推荐用 UUID第二列是挂载点第三列是文件系统类型第四列是挂载选项第五列是 dump 备份标志现代系统基本填 0第六列是开机 fsck 顺序根分区填 1其他填 2不需要检查填 0。删行的时候整行删掉别留下孤立的逗号和空格。5.2 UUID 采集和残留条目的识别技巧用 UUID 挂载是现在的标准做法因为设备名会变。清理时如果发现 fstab 里有 UUIDxxxx 这种条目得先确认这个 UUID 是不是目标盘的。采集方式有几种# 查看某个设备的所有标识 blkid /dev/sdb1 # 列出所有块设备的 UUID 和挂载点 lsblk -f # 按 UUID 反查设备 blkid -U uuid如果你要检查的盘已经拔掉了blkid -U查不到任何东西这就说明这个 UUID 指向的设备已经不存在——但 fstab 里还留着这就是典型的残留条目可以直接清理。这个反查确认法比凭记忆判断可靠得多。还有一种更隐蔽的残留fstab 里用了 LABEL 或者 PARTLABEL 来标识设备而非常见的 UUID。这些标签有可能在 LVM 元数据里也可能在分区表里wipefs 擦除时一般会一起清掉但如果你的 wipefs 只清了分区没清整盘标签可能残余。判断方法同样是反查blkid -L label查不到就是残留。5.3 多路径、udev 和 LVM 配置文件的善后除了 fstab还有几处容易出现残留配置的地方我按重要性列一下多路径配置。/etc/multipath/目录下可能有 bindings 和 wwids 文件记录了之前识别过的多路径设备。用multipath -ll查看当前映射用multipath -f mpath刷掉不需要的然后清理/etc/multipath/wwids里对应的 WWID 行。如果整块盘都下线了wwids 文件里那一行留着会导致下次开机多路径服务尝试重连一个不存在的设备拖慢启动。udev 规则。/etc/udev/rules.d/下可能有针对特定磁盘的自定义规则比如绑定固定设备名、设置权限、配置 raw 设备。检查一下grep -rn sdb\|vg_data /etc/udev/rules.d/命中的规则要么删掉要么改成不匹配。改完udevadm control --reload-rules udevadm trigger生效。LVM 元数据和备份。LVM 会在/etc/lvm/backup/存当前 VG 的元数据快照在/etc/lvm/archive/存历史版本在/etc/lvm/cache/.cache缓存设备扫描结果。删完 VG 之后backup 目录里那个 VG 的文件就成了历史遗留archive 里可能堆了几十个旧版本。这些文件不会导致系统故障但会干扰排查建议清理# 查看有哪些 VG 的备份 ls -l /etc/lvm/backup/ # 确认目标 VG 已经从 vgs 列表里消失后删除对应备份 rm -f /etc/lvm/backup/vg_data # archive 里的历史版本按需清理 ls -lt /etc/lvm/archive/ | head提示动手删 backup 和 archive 之前先用 vgs 确认这个 VG 确实已经不存在了。反过来如果哪天误删了 VG 需要恢复vgcfgrestore靠的正是这两个目录里的文件所以 archive 里的历史版本在盘还没彻底交付出去之前别急着全删。cache 文件比较特殊它会自动重建手动删掉也没事删除后第一次执行 LVM 命令会重新扫描生成只是速度稍慢。如果你遇到明明删了盘lvm 命令还报某个设备不存在的怪现象删掉/etc/lvm/cache/.cache再试往往就好了。还有一处容易被忽略/etc/lvm/lvm.conf里的filter配置。如果之前为了屏蔽某些设备改过 filter现在设备下线的可以把 filter 恢复成默认的宽松模式或者同步更新规则。改完 lvm.conf 后建议跑一次vgs确认扫描正常。5.4 清理之后的完整验证清单配置清理完别急着收工。我固定跑一遍这个验证清单五项都过才算收工findmnt和df -h里看不到目标挂载点。pvs、vgs、lvs里看不到目标卷组和逻辑卷。lsblk -f里目标盘没有任何 FSTYPE、UUID、挂载点信息。mount -a无报错验证 fstab 自洽。dmesg -T | tail -50没有与该设备相关的 I/O 错误或警告。这五项里第三项最容易被跳过但它是判断擦拭是否彻底的直接证据。如果 lsblk -f 里那块盘还显示一个 ext4 或者 LVM_member 的标签说明签名没清干净重启后 LVM 扫描有可能又把它认回来。6. 常见问题速查与踩坑实录6.1 问题速查表把这轮操作里遇到和听说过的问题整理成表出了状况可以直接对号入座报错信息原因解决思路target is busy有进程占用挂载点fuser -muv 定位停服务或退 shellPV is still in use by VGVG 未删除先 vgremove再 pvremoveLogical volume is in useLV 仍被挂载或激活先 umount再 lvchange -anthin pool is in usethin volume 未清空先删所有 thin volumeVG contains LV卷组内还有逻辑卷lvs 确认后逐个 lvremoveCannot access device设备节点已被移除partprobe 重读或删除 lvm cache重启进入 emergency modefstab 残留无效条目加 nofail或删行后 mount -a 验证重启后幽灵设备出现磁盘签名未擦除wipefs -a 清整盘签名6.2 踩坑实录一lazy umount 之后的假象有次我在一个数据同步任务还在跑的时候执行了umount -l命令瞬间返回我以为是卸载成功了接着就执行了 lvremove。结果 lvremove 报错说设备还在用查了半天才发现是那个同步进程还挂着已失效的文件句柄在写。更麻烦的是因为挂载点已经被从命名空间摘掉了进程的错误日志里只有 I/O error看不出是往哪写的。教训很清楚lazy umount 只适合确认没有写入的场景而且用完之后必须用lsof L1检查有没有残留的 deleted 文件句柄全部释放之后才能进行后续的 LVM 操作。现在我基本不用-l了宁可多花时间定位占用进程。6.3 踩坑实录二拿容量判断盘位的惨痛经历规范化操作里最不该犯但最容易犯的错是靠容量来认盘。有次两台同型号服务器都是两块 2TB 数据盘我按 /dev/sdb 认盘结果在第二台上连着两块盘一起操作了。好在当时第二台是测试机数据可以重建如果是生产环境就是事故。现在我的强制流程是先用lsblk -o NAME,SIZE,SERIAL,MOUNTPOINT打出序列号序列号是物理唯一标识不同机器上同一块盘的序列号不会变。确认序列号对应的是目标盘之后再按设备名操作。多花十秒钟避免的是不可逆的损失。lsblk -d -o NAME,SIZE,SERIAL,MODEL,ROTA # ROTA 为 1 是机械盘0 是 SSD/NVMe6.4 踩坑实录三忘删 multipath 的 wwids 导致开机变慢这个坑比较隐蔽。一台服务器下线了两块 SAN 存储盘LVM 和 fstab 都清干净了但没动 /etc/multipath/wwids。结果下次重启多路径服务在启动时反复尝试重连那两个已经不存在的 WWID每次超时几秒整个开机时间从 40 秒拉到了接近三分钟日志里全是 multipathd 的 timeout 记录。排查的时候直接grep wwid /etc/multipath/wwids就能找到删掉对应行再重启就恢复了。如果当时用multipath -f先把映射刷掉再改文件会更彻底一些。6.5 踩坑实录四archive 里翻出救命的元数据这次是反面的例子说明为什么 archive 别急着删。有一次我要回收一块盘VG 里几个 LV 都删了结果操作完才发现其中一个 LV 的实际用途和文档记录不一致业务侧要求恢复。好在/etc/lvm/archive/vg_data_000xx.vg里还留着删除前的元数据快照用vgcfgrestore -f file vg_data把 VG 结构恢复了出来前提是磁盘还没被擦除PV 标签还在数据也顺利找回。这件事之后我改了两个习惯一是回收磁盘时把元数据备份拷贝一份到别的机器上再擦盘二是擦除签名这一步只在业务完全确认之后才做中间留出至少一个工作日的缓冲期。元数据文件不大几十 KB成本极低但关键时刻真的能救命。6.6 个人心得把撤盘当成一次小型变更来管做了这么多轮磁盘上下线我最大的体会是撤盘不是敲几条命令而是一次需要管控的变更。加盘的时候大家都谨慎因为有业务等着用撤盘的时候心态容易松懈觉得删掉就行偏偏撤盘出问题的后果比加盘更严重——加盘失败最多是业务没扩容撤盘失败可能直接导致系统起不来或者数据丢。所以现在我固定的做法是操作前留档lsblk、vgs、lvs 输出全存操作中确认每一步做完验证后再进入下一步操作后缓冲磁盘签名擦除和元数据删除留出观察期。如果这块盘是要交付给别的部门或者别的系统擦除之后再用lsblk -f打一次干净状态截图作为交付凭证。还有一个小技巧分享给经常做批量运维的同学把这套流程拆成侦察脚本和确认清单两部分侦察脚本只读不写一次性输出所有需要的信息确认清单是纯文本每一步执行前打勾。人在连续操作几台机器之后注意力会下降靠脚本收集信息和靠清单强制确认比依赖记性可靠得多。磁盘这行当里最贵的从来不是硬盘是数据。