LVM逻辑卷管理实战：在线扩容与数据盘重装避坑全攻略

遇到过这种情况没：数据库告警说磁盘快满了，你火急火燎跑过去一看，根分区确实只剩几十MB。新硬盘插上，传统思路是分区、格式化、挂载，可麻烦的是一堆数据已经散落在旧分区里，迁移等于要停机。但如果这套系统用了LVM，整个过程就能变成：新盘插上去，加进卷组，把逻辑卷拉伸，文件系统跟着变大，业务甚至不需要重启。我当年第一次在线上把根分区从200G扩到500G没停机时，是真真切切感受到了这技术的价值。这篇就用一台普通Linux服务器当例子，把磁盘管理里的基础逻辑、LVM的完整玩法，还有重装系统前必须处理的"数据盘残留VG"这类坑，一次性说清楚。

文章面向两类人：一是装机时见过系统里那个LVM选项但一直没搞懂的Linux使用者，二是整天跟服务器、云主机打交道的运维新手。不扯虚的，全程命令可复现，最后几节的经验全是我实打实踩过的坑换来的。

1. 磁盘管理基本功：先弄懂分区到挂载的完整链路

1.1 一块新硬盘从插入到可用，中间发生了什么

很多人对磁盘管理的理解停留在"分区、格式化、挂载"三个词，但真出问题时，往往就是中间某个环节卡住了。一块物理磁盘要让Linux真正能用起来，至少要经历这样的过程：物理磁盘被系统识别为设备文件（比如 /dev/sdb），然后在上面建立分区表并划分出分区（比如 /dev/sdb1），接着在分区上创建文件系统（ext4、xfs这类），最后把一个目录挂载到这个文件系统上，用户才能通过 /data 这样的路径往里读写。

这套链路里每条命令都有明确目的。fdisk 或 parted 解决的是"这块盘怎么切"的问题，mkfs 解决的是"这个分区用什么格式来存数据"的问题，mount 解决的是"这些数据挂到哪个目录入口"的问题。我在实际工作中见过不少新手卡在挂载这一步：命令执行没报错，数据也写进去了，重启服务器后目录空了，然后急得满头大汗。原因通常是他们没把挂载信息写进 /etc/fstab，系统重启后不会自动挂载。这里有一条基础规律：凡是需要长期使用的挂载点，都要在 /etc/fstab 里留一条记录，否则下次开机系统不会记得你挂过什么。

1.2 磁盘管理中最容易忽视的两个细节

第一个细节是设备名会漂移。 /dev/sda、/dev/sdb 这种名字是内核按扫描顺序分配的，有时候加了一块新盘，原来的 sda 可能变成 sdb。所以现在的主流做法是拿UUID来标识文件系统，用 blkid 查一下分区的UUID，然后写进 /etc/fstab。我在生产环境见过有人用 /dev/sdb1 挂数据盘，结果机房加了块盘后系统起来挂载失败，整条业务的日志全写到了根分区，直接把根分区撑爆。那个教训很痛。

第二个细节是在非空目录上挂载分区。假设 /data 目录里已经有文件，你把一块新盘挂上去，原目录里的文件不会消失，但会被"藏"在挂载点下面，看起来就像没了。卸载后它们又会回来。这个特性能坑到不少人，尤其是想给已有目录扩容的时候。正确做法是先确认目录是不是空的，或者先备份，再决定要不要直接挂载。

2. LVM核心设计思路：一个"存储池"解决扩容焦虑

2.1 从普通分区到LVM，到底变的是什么

普通分区方案里，磁盘分区和文件系统的关系是"一对一"的：/dev/sda1 就是 /data，它有多大就是多大，想变大就得重新分区，而重新分区经常伴随着数据迁移。LVM改变的是这种绑定关系。它把物理磁盘拆成物理卷（PV），再把多个PV合并成一个卷组（VG），最后从VG里划出逻辑卷（LV）给文件系统用。文件系统看到的是逻辑卷，而逻辑卷只是池子里的一小部分，池子随时可以加新硬盘。

用生活化的类比来说，传统分区像是你住在固定隔间的宿舍，房间大小是建楼时定死的，想换大房间得搬家；LVM则像住进了通间仓库，你用隔板划出自己的区域，想扩面积就把隔板往外挪一格，甚至隔壁空位也能借过来用。这个"隔板可移动"的特性就是LVM最核心的价值：文件系统在逻辑卷上，逻辑卷在卷组里，卷组底下是好几个物理硬盘。无论底层换成多大的盘、加几块新盘，上层的业务看到的始终是一个可以长大的文件系统。

2.2 LVM的优缺点和它真正适合的场景

优点大家听了太多：支持跨磁盘聚合、支持在线扩容、支持快照。但我也必须说清楚代价。LVM在IO路径上多了一层映射，磁盘读写要通过逻辑卷映射到物理卷，理论上会引入轻微性能损耗。实际里对普通数据库和文件服务影响很小，大体上可以忽略不计，但在超高IOPS的存储场景中，这层损耗会被放大，这时候你可能需要评估一下是不是值得用LVM。

LVM另一个容易让人误解的地方是：它能扩容，但缩减并不是都有好下场。ext4文件系统支持收缩逻辑卷，但操作前必须卸载、做文件系统检查，过程比较麻烦；而xfs文件系统从设计上就不支持收缩，只有"增大"没有"减小"。也就是说，你上了xfs+LVM，容量只能一路往里加，想要缩回来基本等于备份后重建。所以做容量规划时，别抱着"反正LVM能缩"的心态，该留的余量还是要留。

适用场景很清晰：根分区和数据分区需要频繁扩容的服务器、要跨多块盘做存储聚合的环境、数据库或文件服务需要做LVM快照做升级前保护的场景。不适合的场景则是那种需要极致单盘IO性能的裸设备服务，或者你已经用了硬件RAID、分布式存储这类更上层的存储抽象。

2.3 你很可能已经在用LVM而不自知

很多Linux发行版安装时的默认选项就包含LVM。CentOS的默认安装就会把你划分给系统的空间做成一个卷组，下面再分出 root、home、swap 这些逻辑卷；Ubuntu Server安装时有一个"使用LVM"的选项，勾上后同样会把系统盘变成LVM结构。包括kylin、统信UOS这些国产系统，安装器里同样支持LVM。所以很多时候你装完系统后用 df -h 看，发现根分区挂在 /dev/mapper/centos-root 而不是 /dev/sda1，这就是LVM已经在底层工作了。

推荐用 lvmdiskscan、pvs、vgs、lvs 这一组命令快速检查当前系统有没有LVM：如果有输出，说明系统里已经有物理卷或卷组了。之后在这些机器上做磁盘管理时，第一反应不应该是直接 fdisk 去扩老分区，而是看看能不能走LVM的通道，把新空间加进卷组里去。

3. 从零搭建LVM：新盘加入与在线扩容实操

3.1 动手前先盘清楚当前环境

假设现在有一台刚装完CentOS的机器，系统盘是 /dev/sda，里面已经有一个卷组叫 vg_system。我又加了一块200G的数据盘，设备名是 /dev/sdb，计划把它做成一个独立的卷组 vg_data，从里面划出100G挂到 /data。第一步永远是查看现状：

• lsblk 看当前块设备树，确认新盘被识别成哪个名字
• pvs / vgs / lvs 看已有的LVM结构，确认卷组名、空闲空间和PE大小

这里有个细节：新盘如果是云主机加的数据盘，有时候 lsblk 看不到。物理机新插入硬盘后，也可能因为热插拔总线没扫描到而找不到设备。这时候可以试试 echo 1 > /sys/class/block/sdb/device/rescan，或者用 partprobe 让内核重新读取分区表。先把设备认出来，后面所有操作才有意义。

3.2 PV、VG、LV的完整创建命令流程

确认设备名是 /dev/sdb 后，我习惯先分区再建PV。直接在整块裸盘上也能建PV，但后续如果想做单盘迁移，或者某块盘要退出卷组，分过区的PV处理起来更干净。用 fdisk 分区时注意这几步：

fdisk /dev/sdb

进入交互界面后依次做：输入 n 创建新分区，直接回车选择主分区，再回车采用默认的起始扇区，结束扇区也直接回车表示占满整块盘；然后输入 t 修改分区类型，在类型代码里输入 8e（Linux LVM），最后输入 w 写盘退出。

分区完成后建PV和VG：

pvcreate /dev/sdb1 vgcreate vg_data /dev/sdb1

vgcreate 这条命令会在建卷组的同时把 /dev/sdb1 初始化成PV，所以前面也可以直接：vgcreate vg_data /dev/sdb1，省掉单独的pvcreate。但一般我还是习惯先pvcreate，因为方便用 pvs 检查分区有没有对齐、有没有异常。

然后创建逻辑卷并格式化挂载：

lvcreate -L 100G -n lv_data vg_data mkfs.xfs /dev/vg_data/lv_data mkdir -p /data mount /dev/vg_data/lv_data /data

最后把挂载信息写进 /etc/fstab，用 blkid 查到的UUID替换：

UUID=xxxx-xxxx-xxxx /data xfs defaults 0 0

写完最好执行 mount -a 验证，保险起见再重启一次确认没有挂载报错。我在这一步吃过亏：fstab 里挂载参数写错，重启后系统直接进入救援模式，排错半天才发现是路径多打了个字母。

3.3 在线扩容是真的"在线"，但要看懂命令参数

扩容是LVM最吸引人的能力。假设运行三个月后， /data 用了90G，100G的逻辑卷快满了。物理盘 /dev/sdb 还有剩余空间，那直接在VG里把没分配的空间划给逻辑卷就行：

lvextend -L +100G /dev/vg_data/lv_data

注意 -L +100G 的加号表示在原有基础上增加100G，没有加号则代表把逻辑卷调整到100G。调整完LV大小后，文件系统还没有变化，xfs要用 xfs_growfs，ext4要用 resize2fs 去扩展：

xfs_growfs /data

如果是ext4，则是 resize2fs /dev/vg_data/lv_data。现在新版系统里的 lvextend 支持 -r 参数，一条命令同时完成逻辑卷扩容和文件系统扩容：

lvextend -r -L +100G /dev/vg_data/lv_data

这个 -r 参数在CentOS 7.4以上版本和主流Ubuntu版本里都能用，非常省事。整个扩容过程中，业务不需要停机、数据不需要迁移，挂载点是 /data 的服务照常读写。我在第一次实操前一直担心在线扩容会不会影响正在写数据的进程，实测下来XFS和ext4的在线扩展机制已经足够成熟，只要你别手滑写错设备名，基本不会出问题。

关于容量计算，LVM内部有个PE（Physical Extent，物理块）的概念，默认PE大小是4MB。创卷组时用 -s 8M 之类参数可以改，但默认4M就够用。扩容时如果习惯按PE数来算，可以用 vgdisplay 看Free PE，比如剩余25000个PE，每个4MB，那能扩的空间就是25000×4MB=100G，命令就可以写成 lvextend -l +25000 或者更省事的 -l +100%FREE。我平时更喜欢直接用 -L 按容量写，直观不容易算错。

3.4 再加一块新盘到底怎么并入已有VG

扩容遇到最尴尬的情况是：VG vg_data 里200G物理空间已经用完了，业务还要继续涨。这时候不要新建VG，直接把新盘加进老VG里。新盘还是 /dev/sdc，重复老流程：

fdisk /dev/sdc # 建分区、设8e分区类型 pvcreate /dev/sdc1 vgextend vg_data /dev/sdc1 lvextend -r -L +100G /dev/vg_data/lv_data

vgextend 的作用就是给"存储池"加一块新砖，池子变大了，LV才能继续扩。这套操作在运维里太常见了，我感觉LVM最大的价值就是让"加硬盘"变成一个填空题，而不是重新做一遍五步操作。如果你在云平台上，新数据盘挂载到系统后同样遵循这个流程：lsblk看到盘、分区、pvcreate、vgextend、lvextend -r，一气呵成。

4. 重装系统前必须先处理LVM数据盘：完整避坑流程

4.1 典型翻车场景：重装完系统，数据盘"失联"了

这个话题确实很多人问，尤其是用云电脑、云服务器，或者物理机装系统时选了LVM并把数据盘也并进了一个卷组的情况。典型场景是：系统盘和数据盘在旧系统里都是同一个VG的成员，比如系统盘是 /dev/sda，数据盘是 /dev/sdb，它们都属于 vg_data。你因为系统故障想重装操作系统，直接在管理平台点了重装，装完发现数据盘上的逻辑卷还在，但无论怎么挂载都提示找不到文件系统，或者新系统安装器在安装过程中一直警告"检测到LVM物理卷，是否格式化"。

原因其实不复杂：旧系统里数据盘带着PV和VG的元数据，重装系统盘时，安装器扫描到了这块带有LVM标记的磁盘。如果安装器问你是否格式化，手一抖选了是，数据盘上的逻辑卷元数据就没了。就算你没格式化，数据盘上残留的VG状态信息也可能和新系统的LVM状态对不上，导致新系统无法自动激活卷组。更麻烦的是，某些平台的系统盘重装会重刷启动分区，而数据盘还保持着旧VG的激活状态，两边信息一冲突，系统起来后一切看起来都在，就是挂不上。

4.2 重装前标准处理流程：分离VG和物理卷

我整理了一套操作，每次重装系统前照着做，能省掉后面一大半麻烦。核心就一句话：重装前把数据盘从LVM体系里"请出去"。

第一步，备份。重装系统这件事，无论怎么操作都有风险，至少把关键数据拷到别的机器，或者做一个云平台快照。备份不是流程里可选项，是必选项。

第二步，在旧系统里停用所有相关挂载点和卷组。先在 /data 这种挂载点上 umount，让业务数据先落盘。然后停用卷组：

umount /data vgchange -an vg_data

在这一步之后，旧系统已经不再使用 vg_data 里的逻辑卷了。如果你要把数据盘从承载系统的新机器上彻底去掉、数据也不要了，那就直接删掉数据盘上的PV：

pvremove /dev/sdb1

如果数据盘上的数据还要留着，物理盘也要继续接到重装后的系统上用，那就不要做pvremove，而是应该在重装前把数据盘从系统上分离。云平台控制台通常都有"卸载数据盘"或者"分离硬盘"这种功能，先卸掉再重装系统盘，装完再挂回来，这是最干净的方式。

4.3 重装后如何把数据盘重新接入新系统

如果重装前已经把数据盘分离，装完系统再把数据盘挂回去，这时候在新系统上执行扫描和激活：

pvs vgscan vgchange -ay lsblk

vgscan 会扫描所有磁盘上的LVM元数据，找到存在的卷组，然后 vgchange -ay 把卷组激活。激活后再 mount 对应逻辑卷，比如 mount /dev/vg_data/lv_data /data。这里要注意：新系统的挂载点目录得重新建，/etc/fstab 里的挂载记录也要重新写，因为旧fstab已经在重装时被覆盖了。

如果重装平台没有给你分离数据盘的机会，旧系统又已经没了，那可能得进LiveCD环境或者新安装器的shell中手动操作：同样执行 vgscan、vgchange -ay，先把卷组激活，再把数据挂出来备份，然后处理。这个流程比较折腾，所以我一直强调重装前分离或者删除是正规做法。还有一个额外提醒：重装系统后，如果看到一个VG名和新系统卷组名冲突了，比如旧系统卷组叫 centos，新系统安装时也用了 centos 这个名字，那么新系统启动后可能不会自动激活旧卷组，因为名字撞车了。这种情况可以用 vgrename 改名，但操作前建议先备份好数据。

5. LVM常见问题与排查技巧实录

5.1 扩容后文件系统没变大？八成是忘了扩展文件系统

这个事儿我见得太多了。 lvextend 把逻辑卷从100G扩到200G，df -h 一看还是100G，第一反应往往是"命令是不是没生效"。其实命令生效了，只是文件系统还不知道自己有这么多空间可用。逻辑卷是给文件系统的"容器"，容器变大了，文件系统得自己把新空间纳入管理范围。xfs用 xfs_growfs，ext4用 resize2fs，两者都是在线操作，不需要卸载。早期 lvextend 不带 -r 时特别容易犯这个错，现在新系统支持 -r 后建议直接用：

lvextend -r -L +100G /dev/vg_data/lv_data

-xfs文件系统执行 xfs_growfs 时通常要指定挂载点，比如 xfs_growfs /data，它不需要写设备路径，这是xfs和ext4一个常见的区别。

5.2 开机起不来：/etc/fstab 里到底该写UUID还是设备名

这个问题横跨LVM和普通分区。我自己的原则很简单：能用UUID就不用设备名。LVM逻辑卷有稳定的设备路径 /dev/mapper/卷组名-逻辑卷名，这个路径一般不会变，但底层物理盘如果是多路径或者USB外接盘，设备节点就不稳定了。用 blkid 查逻辑卷的UUID，然后写进fstab：

blkid /dev/vg_data/lv_data

然后编辑 /etc/fstab，把输出里的 UUID=... 那一长串填进去。开机后如果发现系统进入紧急模式，先别慌，输入 root 密码后在shell里执行 mount -a，看具体是哪个挂载点报错，原因通常有两种：UUID写错，或者文件系统类型写错。用 xfs 格式化却写了 ext4，mount时就会报 unknown filesystem type。

5.3 卸载不掉/删不掉的设备，怎么定位是谁在占用

执行 umount 提示 target is busy，或者用 fdisk 删分区时提示 device is busy，在白天的生产环境十有八九是有进程正在读写。想快速找出来谁占用了这个目录，用 fuser 或者 lsof：

fuser -km /data lsof +f -- /data

fuser -km 会杀掉占用 /data 目录的所有进程，威力很大，别在生产环境随便用，真要用也先确认这些进程是能杀的。更温和的办法是用 lsof 列出占用文件的进程，然后把进程停了或重启后再卸载。还有一个冷门但实用的场景：明明 umount 成功了，fdisk 删除分区仍提示 busy，可能是LVM还在引用这个PV。确认逻辑卷已经不再使用后，执行 pvremove 前先 vgreduce 把PV从VG里摘掉，或者直接 vgremove 干掉整个VG，再来处理分区。

5.4 LVM快照：一个极易被低估的备份利器

最后聊一个很多人没用过的功能：LVM快照。它能在几乎不影响系统运行的情况下，给逻辑卷拍一张"当时状态"的照片，后续可以合并回去。我用它做过数据库升级前的保护：先给数据卷做快照，然后升级软件版本，如果出问题，直接 lvconvert --merge 把数据卷回滚到升级前的状态。

创建快照的典型命令：

lvcreate -L 20G -s -n lv_data_snapshot /dev/vg_data/lv_data

这里 -s 是 snapshot 的意思，-L 20G 是给快照预留的空间，不是快照大小。LVM快照采用的是Copy-on-Write技术，快照创建瞬间几乎不占空间，只有被修改的数据块才会被复制到快照区域。所以快照空间配额给数据卷的10%-20%通常就够一个短期的安全窗口；如果快照区写满了，快照会失效，会自动变成只读甚至不可用。这个特性很实用，但别把快照当长期备份用，它天然是"临时保护"而不是"归档库"。

5.5 常用排查命令与对应问题速查表

这个表建议收藏，基本覆盖了LVM日常操作的八成的坑。

6. 基于实战的几条运维建议

6.1 先想清楚怎么缩，再决定怎么扩

现在很多教程教你LVM怎么扩容，却很少提缩减有多麻烦。XFS文件系统不能缩减，这是一条硬性限制。所以创建文件系统时，如果预期有缩减需求，就选ext4；如果不考虑缩减，xfs的高性能和稳定性更省心。比如数据库的归档目录、日志目录这种只会越来越大的，我一般直接xfs；临时目录、开发环境里可能要反复调整空间的，用ext4会更灵活。文件系统的选型更像一种提前约定，LVM给了上层空间弹性，但文件系统决定了下层能不能自由伸缩。

6.2 重装前先分离数据盘是最高优先级

这条放在最后说，是因为它最容易被忽略却最容易致命。无论你是物理机重装系统，还是云平台控制台重装系统盘，只要数据盘还在系统里并且带着LVM元数据，重装过程就可能触发安装器自动识别、自动格式化。前面辛辛苦苦攒的数据，可能毁在几个回车键上。我的固定流程是：备份、umount、vgchange -an，有条件的把数据盘物理分离/卸载，重装完成后挂回来再 vgscan、vgchange -ay。这套流程走顺了，你会发现重装系统不再是一次胆战心惊的赌博。

最后再分享一个经验之谈：LVM快照别只当成游戏里的"存档机制"。我在每次升级前都会随手打一个快照，很多时候这个快照会成为救命的船票。快照空间给充裕一点，用完及时合并或删除，不占日常空间，但关键时刻能顶上大用。这就是LVM，越用越顺手的存储层工具，只要尊重它的规则，它的回报相当可观。