企业官网建设流程全解析

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 -o+pv_used,pv_free vgs -o+vg_free,lv_count,pv_count lvs -o+lv_size,seg_count,segtype,lv_attr

lsblk 的-f会带出文件系统类型和 UUID，这个 UUID 后面清理 fstab 时要用到，先记下来。pvs/vgs/lvs 这三个命令输出非常紧凑，建议加上-o+扩展字段，能直接看到 PV 已用/剩余、VG 里有多少 LV 和 PV、LV 的分段类型。特别要留意 lv_attr 这个属性列，第一位的字母代表卷类型：t是 thin pool，V是 thin volume，s是快照，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 失败原因整理成了一张表，按出现频率排的：

关于umount -l（lazy）和umount -f（force），我的态度是：能不用就不用。-l是把挂载点从命名空间里摘掉，但内核里实际还挂着，等所有引用释放后才真正卸载，看起来命令立刻返回了，实际上数据可能还在写。-f主要用于无响应的网络文件系统，本地盘用它基本等于放弃了数据一致性检查。真要动这两个参数，前提是先sync三遍，并且确认业务已经彻底停止。

3.3 swap 分区也要走卸载这一步

如果这块盘上有 swap 逻辑卷，光 umount 是没用的，得先 swapoff。检查当前 swap 用cat /proc/swaps或者swapon --show，找到目标后执行swapoff /dev/vg_data/lv_swap。swapoff 会触发内存页回迁，如果 swap 里存了几 GB 数据，这一步可能耗时几十秒甚至几分钟，命令会看起来像卡住了，别急着 Ctrl+C。

回迁期间系统内存占用会上升，所以如果当前内存本来就紧张，最好挑业务低谷期做，或者先把不重要的服务停掉腾出内存。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 的删除有两种做法。一种是直接lvremove，LVM 会自动帮你处理停用；另一种是先vgchange -an <vg>把整个卷组停用，再删。日常单机环境直接 lvremove 就够了，但在共享存储或者集群环境里，必须先vgchange -an释放锁，否则删除操作会被 lock 挡住。

停用这一步在排查问题时也很有用。lvchange -an /dev/vg_data/lv_app会断开设备映射，让系统"看不见"这个逻辑卷，但元数据还在，随时能-ay激活回来。这是个无损的中间态，可以拿来做验证：停用后如果没有任何服务报错，说明确实没人在用；如果有服务立刻报错，那说明还有依赖没理清。

删 LV 之前先看一眼它的分段情况。lvs -o+segtype,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确认一下，列表里已经没有目标卷了。然后再看vgs，VG 的 Free Size 应该相应增加。如果 Free Size 没变，说明 LV 没删干净或者有快照占着。

4.3 删除卷组和物理卷

LV 清空之后，VG 里应该只剩元数据了。删 VG：

vgremove vg_data

如果 VG 里还有残留 LV，vgremove 会拒绝并提示。这时候回到上一步继续清理，别用-f强推。vgremove 完成后再看pvs，对应 PV 的 VG 字段应该变成空。

最后删 PV：

pvremove /dev/sdb1

pvremove做的事情是把磁盘头部的 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 的幽灵设备，甚至自动激活成卷组。所以下线盘的最后一步必须是擦除签名。

三种方式，适用场景不同，我做了个对比：

我的习惯顺序是：先wipefs -a /dev/sdb，再用wipefs -a /dev/sdb1把每个分区也清一遍（如果分区还在），然后partprobe /dev/sdb让内核重读。如果这块盘要转给别的系统用，或者盘上有过敏感数据，再加一步 dd 清头部。

对于 SSD，blkdiscard是最彻底的，它会触发闪存块的擦除，比 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-timeout=5，这样设备不在时系统也能正常启动，只是这个挂载点空着。观察一两周确认没人用，再彻底删掉这一行。

# 修改前先备份 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 里有 UUID=xxxx 这种条目，得先确认这个 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 清理之后的完整验证清单

配置清理完，别急着收工。我固定跑一遍这个验证清单，五项都过才算收工：

1. findmnt和df -h里看不到目标挂载点。
2. pvs、vgs、lvs里看不到目标卷组和逻辑卷。
3. lsblk -f里目标盘没有任何 FSTYPE、UUID、挂载点信息。
4. mount -a无报错（验证 fstab 自洽）。
5. dmesg -T | tail -50没有与该设备相关的 I/O 错误或警告。

这五项里第三项最容易被跳过，但它是判断擦拭是否彻底的直接证据。如果 lsblk -f 里那块盘还显示一个 ext4 或者 LVM_member 的标签，说明签名没清干净，重启后 LVM 扫描有可能又把它认回来。

6. 常见问题速查与踩坑实录

6.1 问题速查表

把这轮操作里遇到和听说过的问题整理成表，出了状况可以直接对号入座：

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/NVMe

6.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打一次干净状态截图，作为交付凭证。

还有一个小技巧分享给经常做批量运维的同学：把这套流程拆成"侦察脚本"和"确认清单"两部分，侦察脚本只读不写，一次性输出所有需要的信息；确认清单是纯文本，每一步执行前打勾。人在连续操作几台机器之后注意力会下降，靠脚本收集信息和靠清单强制确认，比依赖记性可靠得多。磁盘这行当里，最贵的从来不是硬盘，是数据。