LVM逻辑卷管理实战：从创建到扩容的完整指南

1. 传统分区与LVM的差距：三个让我转向LVM的真实场景

先说说我自己遇到的事。几年前我负责一台内部测试服务器，跑着MySQL和几个Java应用，系统盘当时只给分了40G。某天下午告警邮件突然弹出来，根分区用了98%。我当时想的不是扩容，而是先琢磨哪个目录能清——这是传统分区最大的问题：分区大小在装系统时就被"焊死"了，事后想改只能靠软链接、挂新盘、搬家这类笨办法。那天我最后是清了日志、删了旧安装包，勉强腾出几个G，但所有人都知道这只是续命，不是治病。

第二个场景更常见。业务数据增长很快，当时买服务器时只配了一块600G的盘，一年多以后就见底了。传统方案是再买一块盘，格式化，挂到某个目录，然后把应用的数据目录指过去。听着顺理成章，但实际一操作就难受了：历史数据在旧盘，新数据在新盘，应用里全是绝对路径，各种配置文件要改，备份脚本要改，监控要改。整个迁移过程小心翼翼，生怕哪个程序还写着老路径。这个场景让我彻底意识到：传统分区把"一块盘的容量"和"一个目录的空间"绑死了，而业务需要的是"目录空间可以跨多块盘自由分配"。

第三个场景是缩容和快照。有一次QA环境需要把某个分区从200G缩到120G，腾出的空间给另一个压力测试用。传统分区想缩容？几乎不可能，只能重新分区、重新格式化、重新恢复数据。折腾一个周末。而LVM（逻辑卷管理）用一句话就能概括它的价值：它把"物理磁盘"和"文件系统看到的空间"之间加了一层抽象，于是你可以在系统运行状态下自由地扩容、缩容、跨盘合并、做快照。换句话说，传统分区管理的是"盘子"本身，LVM管理的是"盘子里的空间池"，然后从池子里按需舀水。

第三个场景对做服务器运维和私有云的人来说尤其重要。你装了一台机器，初始规划不可能完全准确，预测未来一年的数据增长本来就是伪命题。有了LVM，磁盘管理就从"分区规划"变成了"容量分配"，后者的灵活度完全不一样。这也是为什么主流Linux发行版在安装时默认推荐LVM布局，云厂商的镜像也在大量使用。如果你还没接触过LVM，或者用过但只停留在"会看不会操作"的水平，这篇文章就是把我在各种环境里摸爬滚打的经验系统整理一遍。

2. LVM四层结构拆解：从物理盘到文件系统的完整链路

理解LVM，务必先理解它的层次。很多教程起手就讲命令，不讲结构，结果使用者一遇到问题就懵。我习惯把LVM拆成四层来说，从上到下分别是：文件系统层、逻辑卷层、卷组层、物理卷层。

2.1 四层各自扮演什么角色

物理卷（PV，Physical Volume）是LVM的地基。它可以是整块磁盘（比如 /dev/sdb），也可以是磁盘上的一个分区（比如 /dev/sda2）。但不管是哪种，这块盘/分区必须先被标记为"LVM成员"，也就是执行 pvcreate 之后，它才叫物理卷。打个比方，PV相当于你买回来的一袋袋水泥，水泥本身没有房子属性，但它是盖楼的原材料。

卷组（VG，Volume Group）是核心的"空间池"。一个VG可以汇集一块或多块PV的空间，把这些空间的来源彻底打散。比如你有两块1T的盘都做成PV，加入同一个VG，这个VG就是2T的容量池。分配空间时，LVM不会关心数据具体落在哪块物理盘上，它只管理Pool里的空间块。套用上面的比方，VG就是把几袋水泥倒进一个搅拌池里，你不再关心哪一瓢水泥来自哪一袋。

逻辑卷（LV，Logical Volume）是从VG里划出来的"虚拟分区"。你对LV做的事与现实分区完全一样：格式化、挂载、读写文件。区别在于，LV的容量可以从VG里随时增加或减少，不用动物理存储。好比从搅拌池里浇一块预制板出来，预制板可以随时再加水泥变厚。

文件系统（Filesystem）就是挂在LV之上的ext4、xfs那一层。需要特别注意的是，LVM本身不管文件系统的事，扩容LV后你还要单独告诉文件系统"空间变大了"，否则内核识别了更大容量，但文件系统还是按旧大小工作。这一步骤很多人漏掉，我在后面会重点讲。

2.2 PE这个参数为什么重要

还有一个隐藏概念叫PE（Physical Extent，物理扩展块），它是VG分配空间的最小单位，默认4MB。你在 lvcreate 时看到的 -l 参数，单位也是PE，比如-l 100表示分配100个PE，即400MB。而-L 100M则是按容量分配。PE设多大直接影响两点：一是大VG下如果PE太小，元数据管理开销变大；二是PE小则空间分配碎块少，PE大则管理轻量但可能浪费空间。日常使用保持默认4MB完全够用。

2.3 一图流看懂数据的流动路径

整条链路用文字描述就是：

应用程序读写文件 → 通过文件系统（ext4/xfs）→ 落在逻辑卷（LV）→ 逻辑卷从卷组（VG）分配空间 → 卷组把空间映射到物理卷（PV）→ 最终读写物理磁盘。

这个过程对上层完全透明。文件系统看到的只是一个设备文件（比如 /dev/mapper/vgdata-lvdata），它不知道自己后面还藏着多块物理盘。这与你用fdisk直接分区最大的区别：直接分区是"分区表写死"，LVM是"逻辑映射动态调整"。

基础查看命令也要先熟起来，这三条基本每天都会用：

pvs # 查看物理卷：哪个设备是PV、属于哪个VG、大小多少 vgs # 查看卷组：VG总容量、已分配、剩余空间 lvs # 查看逻辑卷：LV名字、所属VG、大小、路径

配合lsblk可以直观看到"物理盘 → 分区 → PV → 挂载点"的关系树，这个后面会讲。先把四层结构“焊”在脑子里，后面所有操作才不容易跑偏。

3. 服务器上快速摸清磁盘家底：必用命令与输出解读

不管你是接手一台新服务器，还是在排查磁盘告警，第一步永远是搞清楚"机器上到底有几块盘、怎么分区的、空间用到了什么程度"。这步做扎实了，后面动刀才敢下结论。

3.1 lsblk：磁盘与挂载关系一图看全

我最推荐先跑 lsblk，它对新手最友好，输出是一棵清晰的树状结构。例如：

$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 499G 0 part └─vgroot-lvroot 253:0 0 120G 0 lvm / └─vgroot-lvdata 253:1 0 379G 0 lvm /data sdb 8:16 0 2T 0 disk └─vgdata-lvbackup 253:2 0 2T 0 lvm /backup

注意 sda2 下面缩进的vgroot-lvroot和vgroot-lvdata，说明这块分区是PV，被分成了两个逻辑卷，分别挂载到/和/data。TYPE列里的lvm直接告诉你这是LVM逻辑卷设备。sdb 整块盘也做成了LVM。看到这棵树的瞬间，你就该明白：sda2这块499G的分区并不是直接分配到一个目录，而是进入了vgroot这个空间池，然后池子被划分成120G根卷和379G数据卷。

3.2 df：文件系统视角的使用率

lsblk看的是"分配关系"，df看的是"文件系统使用率"。日常告警盯的就是df。

$ df -hT Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/vgroot-lvroot ext4 118G 89G 23G 80% / /dev/mapper/vgroot-lvdata ext4 372G 200G 152G 57% /data

-T显示文件系统类型，这个信息在扩容时极其关键：ext4和xfs的处理方式完全不同，后面说。设备名里出现的/dev/mapper/xxx就是LVM逻辑卷的映射路径，名字规律是vg名字-lv名字。如果看到的是/dev/sda1这类直接设备路径，说明这个分区没走LVM，是传统分区布局。

3.3 判断一块盘是否属于LVM的两种方式

一是看 lsblk 的TYPE列有没有lvm，二是用blkid查看设备是否有LVM元数据：

$ blkid /dev/sdb /dev/sdb: UUID="xxx" TYPE="LVM2_member"

TYPE是LVM2_member就说明这是物理卷成员。如果是ext4或xfs，则说明这个设备已经被格式化成文件系统直接使用了。这块知识在排查"为什么这块盘挂不上"时特别有用——很多人拿到一块旧盘，直接mount报错，就是因为压根没意识到它曾是LVM成员，需要用pvscan和vgscan先看看它的归属。

3.4 服务器上看磁盘的完整排查套路

我给大家总结一条我日常用的命令链路，照着跑一遍，磁盘家底基本全部暴露：

lsblk # 看物理盘、分区、LVM、挂载点整体结构 df -hT # 看文件系统使用率，确定告警级别 pvs && vgs && lvs # 看LVM三层各自的分配明细 fdisk -l # 确认每块物理盘的总容量和分区表类型 cat /proc/meminfo | head -1 # 顺带看一眼内存，排查磁盘问题时经常要结合内存看

这一套跑完，你脑子里应该能回答出四个问题：机器上有几块物理盘；哪些盘/分区被LVM接管了；每个VG的池子还剩多少空间；当前哪个挂载点快满了。回答不了这四个问题之前，不要动任何扩容或者迁移的念头。这些命令的输出全都可以复现，没有任何门槛，关键是形成"看树→看表→看池子"的习惯。

4. 从零做LVM：物理卷、卷组、逻辑卷的完整创建思路

掌握了怎么看，下一步就是动手。很多新手在创建LVM时容易犯一个错误——直接把整块盘做成PV，结果之后想调整分区时反而没有操作空间。我下面给的流程是经过多次生产验证的标准步骤，每一步都会解释为什么这样设计。

4.1 场景假设与目标

假设新买了一块2T的盘/dev/sdb，目标是把这块盘变成LVM卷组vgdata的一部分，并从中创建一个500G的逻辑卷lvapp，挂载到/app。这个场景在真实运维里非常典型：加新盘、扩充空间池、为新业务划分独立逻辑卷。生产服务器建议给每个业务/用途建独立LV，而不是一股脑全塞到根卷里。独立LV的好处是：各个业务的空间可以独立扩容缩容、独立做快照、独立卸载迁移，互不干扰。

4.2 标准创建命令序列

第一步：在/dev/sdb上创建物理卷：

pvcreate /dev/sdb

如果你不确定 /dev/sdb 是否已有数据，先跑pvs或blkid确认它 "干净"。pvcreate会写入LVM元数据，破坏原有分区表和文件系统，这是不可逆操作，务必三思。

第二步：创建卷组。如果是要新建卷组：

vgcreate vgdata /dev/sdb

如果是往已有的vg（比如系统装好后就有的vgroot）里加盘：

vgextend vgroot /dev/sdb

这里有一个很关键的设计考量：新盘加入已有VG和创建新VG，两者决策路径完全不同。如果新盘容量是想独立使用、长期固定给某个应用，建议新建VG；如果想融入现有空间池、给现有逻辑卷扩容，则用 vgextend。混合式也可以，比如新盘一部分加入vgroot给根卷扩容，剩下的划给新VG，这个看现场需求。

第三步：创建逻辑卷：

lvcreate -L 500G -n lvapp vgdata

这条命令表示：在 vgdata 卷组里创建一个名为 lvapp 的500G逻辑卷。lvm默认的主设备路径是/dev/mapper/vgdata-lvapp，同时也会生成/dev/vgdata/lvapp这种兼容路径。两条路径指向同一个东西，你实际操作时用哪个都行，但配置文件里尽量统一用/dev/mapper/xxx形式，避免在某些发行版上调用的符号链接不一致导致挂载失败。

如果想把VG里的剩余空间全部分配给逻辑卷，用-l 100%FREE：

lvcreate -l 100%FREE -n lvapp vgdata

建议明确指定容量，预留一部分空间在VG里，后续扩容才有余地。除非这个LV就是奔着"占满整个池子"去的。

第四步：格式化并挂载：

mkfs.xfs /dev/mapper/vgdata-lvapp mount /dev/mapper/vgdata-lvapp /app

xfs和ext4选择看场景。xfs在大型文件和高吞吐场景表现更好，但不能缩容；ext4灵活度更高，可缩可扩，但单文件系统上限和文件数量上限低于xfs。云服务器上常用xfs（比如阿里云默认就是xfs），很多企业内部自建环境沿用ext4。小白想省心，小分区用ext4，大数据量场景用xfs。

第五步：写入fstab实现开机自动挂载。用UUID而非设备名，因为设备名（比如 /dev/mapper/vgdata-lvapp）在系统重启后有变化风险，UUID是绝对稳定的标识。先查询UUID：

blkid /dev/mapper/vgdata-lvapp

将输出结果中的UUID复制，编辑 /etc/fstab：

UUID=xxxx-xxxx /app xfs defaults 0 0

这里有个经验之谈：写完fstab后不要立即重启系统验证，而是先执行mount -a，这条命令会根据fstab重新挂载所有项目。如果语法或配置有问题，mount -a 会当场报错，你可以马上修正，而不是等重启进不了系统才后悔。修改fstab导致开机无法挂载、卡在Emergency Mode的情况，我见过太多，全都是跳过这步导致。

4.3 为什么不建议把整块盘直接格式化成文件系统

这次创建流程里最值得讲清楚的问题是"为什么非要绕一层LVM"。答案是：对服务器而言，磁盘容量预测几乎不可能准确。你直接mkfs.xfs /dev/sdb然后挂载，用满之后怎么办？只能再买一块新盘，数据搬过去，路径重新指；如果用LVM，用满时只需再买盘、vgextend进VG、lvextend扩LV、文件系统在线扩容，四步结束，服务全程不停。多花的那一点创建时间，换回的是未来扩容时省下的大把维护窗口。这就是我在生产环境里几乎不裸格式化的原因。

5. Ubuntu根分区扩容全攻略：从加盘到在线扩完的完整操作

热词里有人搜“ubuntu根分区扩容全攻略:lvm”，这几乎是云上Linux用户最常遇到的另一个需求。Ubuntu默认安装时通常使用LVM布局，但很多用户在规划磁盘时不了解扩容的正确姿势，总是在根分区将满时手忙脚乱。这里我直接给出从"新物理盘接入"到"根分区真正变大"的完整流程，并解释每一步背后的逻辑。

5.1 确认你用的文件系统类型

先看清楚扩容对象是ext4还是xfs，决定最后一步的差异：

df -T /

Ubuntu默认一般是ext4（云镜像定制另说），但也有版本/厂商镜像用xfs。记下文件系统类型，下面最后一步会用到。

5.2 扩容操作全流程

假设机器在当前虚拟机里增加了一块100G的新盘，设备名为 /dev/sdb，目标是把这100G全部并入根卷所在的VG，然后全部扩给根LV。

第一步：操作系统识别新盘。虚拟机/云控制台添加磁盘后，有的系统会自动识别，有的需要触发重新扫描。先执行 lsblk 看是否出现 /dev/sdb。如果没出现，执行：

echo 1 > /sys/class/scsi_host/host0/scan

若host0不行，把 host0 换成 host1、host2 逐个试。云上Ubuntu一般添加后立即可见，物理机则需要触发扫描。

第二步：创建PV并并入现有VG。先看当前VG名字：

vgs

假设显示VG名为ubuntu-vg，则执行：

pvcreate /dev/sdb vgextend ubuntu-vg /dev/sdb

vgextend之后，VG的剩余空间会增加100G。可以用 vgs 确认。

第三步：扩展逻辑卷。先看根LV的名字：

lvs

假设根LV路径是/dev/ubuntu-vg/ubuntu-lv。将VG剩余空间全部扩给它：

lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

+100%FREE表示把VG当前所有空闲空间都加给这个LV。注意这里不是逻辑卷扩容后文件系统就自动变大，所以必须做第四步。

第四步：扩展文件系统。这是最容易踩坑的分水岭：

• 文件系统是 ext4：

resize2fs /dev/ubuntu-vg/ubuntu-lv

• 文件系统是 xfs：

xfs_growfs /

两个命令最重要的区别：resize2fs 的参数是逻辑卷设备路径，而 xfs_growfs 的参数是挂载点。xfs文件系统不支持缩容，扩容只能朝一个方向走；ext4可以缩容，但缩容操作只能在卸载状态下进行，风险高，如果不是必要情况不建议缩。我的建议，只要是生产环境且没有明确必须缩容的理由，从一开始就把空间规划到宽松一点，别指望缩容解决问题。

第五步：验证。df -h 看看 / 的容量，应该已经变成原有容量加上100G（考虑少量元数据损耗）。

5.3 实际扩容过程中的注意事项

新盘加入VG时不能忽略PV创建这一步。很多人直接在 vgextend 里填 /dev/sdb，系统会报错说不是物理卷。所以顺序必须是 pvcreate → vgextend，这个顺序不能乱。

根分区扩容时，如果/boot也是独立分区且空间不足，那是另一码事，需要单独处理。LVM扩容解决的是根文件系统（/）的容量问题，不解决/boot。如果/boot是独立分区且满了，只能清理旧内核。清理旧内核的命令是 apt 系列中apt autoremove --purge的活，rootfs扩容帮不上忙。

在线扩容对生产环境是安全的，因为lvextend和resize2fs/xfs_growfs都支持热操作，不会中断正在进行的读写。但你仍然应该选择一个低峰窗口执行，避免极端的IO竞争。还有一条铁律：扩容前做快照或备份，尤其是数据库、状态类应用。LVM虽然可以让扩容变得低风险，但任何磁盘操作在完全不可控的环境里都有翻车的概率，备份是底线。

6. 云电脑与数据盘的特殊处理：重装系统前为什么要先从LVM卸掉

热搜词里有一条很有意思："如果云电脑使用了lvm(逻辑卷管理)并加入了数据盘，用户在重装前需要先从lvm卸"。这其实是云服务器/云电脑用户非常容易踩的一个大坑，而且网上这方面的完整解释反而少。

6.1 为什么会踩这个坑

先说背景。很多云电脑/云服务器创建时会默认系统盘使用LVM，同时允许用户单独购买一块数据盘，并把这块数据盘也做成了PV并加入了根卷所在的VG。这个过程通常是自动化的镜像脚本干的，用户可能都没察觉到。结果重装系统时，用户往往只在控制台勾选了"重装操作系统"，没有从系统里把数据盘的PV解除。

重装后的系统是一个全新的根VG，VG的UUID变了，PV的元数据也可能已经变化。这时你把当时那块数据盘再挂载回新系统，新系统的LVM去扫描时，可能同时遇到两个VG产生冲突——旧VG残留信息还在数据盘上，新VG是新生成的。常见的混乱表现是：

• 新系统无法正常挂在数据盘，因为设备已经有了LVM成员标识，文件系统层面根本看不到数据；
• 挂载时报错说设备忙/结构需要清理/UUID不匹配；
• 更糟糕的情况下，有人在重装时对系统盘做了重新分区初始化，数据盘的PV元数据没有清除，后续系统启动时LVM识别混乱，连引导都可能受影响。

6.2 正确的事前处理流程

如果你确定机器上有一块数据盘曾经被纳入了LVM，在重装前一定要按以下顺序在旧系统里操作：

第一步：卸载数据盘上的文件系统。先查挂载情况：

df -h lsblk

找到数据盘对应的挂载点（比如 /data），卸载它：

umount /data

如果umount提示设备忙，说明有进程还在使用。用 lsof 或 fuser 找出占用进程处理后再卸。

第二步：把数据盘的PV从VG中移除。先用 pvs 确认PV设备名，比如 /dev/vdb。然后：

vgreduce vgname /dev/vdb

vgname 是数据盘所在VG名，pvs 输出里能看到。vgreduce 的含义是"把这个PV从VG成员中拆掉"，之后VG不再依赖这块盘。

第三步：清除PV标记：

pvremove /dev/vdb

pvremove 会清除 /dev/vdb 上的LVM元数据，让这块盘重新变成一块干净的普通磁盘。做完这步，数据盘上已经没有任何LVM痕迹了（文件系统数据本身依然保留，pvremove 不会动数据区，只会擦掉LVM头部的元数据）。

第四步：在云控制台/管理面卸载数据盘。此时数据盘已经完全脱离系统，可以安全地从云电脑上解绑。

6.3 万一已经带着LVM重装了怎么办

如果没做上述处理就重装了，也别慌，还有挽救路径。新系统起来后，执行 vgscan 和 pvscan 看看能否识别旧VG：

pvscan vgscan lvs

如果 pvscan 能看到盘上有PV，并且 vgscan 能恢复旧VG，往往可以用 vgchange -ay 激活这个VG。但小心，如果新系统和旧数据盘的VG同名，LVM默认不会同时激活两个同名VG，需要先重命名其中一个。重命名VG命令是：

vgrename oldvg newvg

之后就可以 mount 相应的LV来拷数据。不过这个过程确实繁琐，而且一旦旧VG的元数据被破坏，数据恢复只能依赖备份工具，所以尽量在重装窗口前按正规流程处理，而不是事后补救。

7. 麒麟Linux扩LVM：国产系统下的步骤差异与典型坑点

热词里出现了“kylin linux 扩lvm”，这又是一个实际环境中经常遇到的需求。麒麟系统分银河麒麟（基于CentOS/RHEL系）和优麒麟（基于Ubuntu系），用户遇到的扩容问题通常集中在银河麒麟上，因为很多政府、企业服务器部署的是这个版本。下面以银河麒麟为主讲差异和坑。

7.1 银河麒麟与CentOS系LVM工具的一致性

本质上，银河麒麟的LVM功能与CentOS 7/8几乎完全一致。lvm2 工具链、内核设备映射机制、/dev/mapper 路径都没差异。所以 CentOS 的LVM扩容命令在银河麒麟上同样适用：

yum install -y lvm2 # 如果没装的话 pvcreate /dev/sdb vgextend centos-vg /dev/sdb # 注意VG名，银河麒麟装系统时默认可能是 vg_root 或你自定义的名字 lvextend -l +100%FREE /dev/vg_root/lv_root resize2fs /dev/vg_root/lv_root # ext4 # xfs： xfs_growfs /

看起来跟Ubuntu差不多，但实际坑点有两个。

7.2 坑点1：默认VG名不统一

银河麒麟安装时的默认分区方案，不同版本、不同架构的命名并不统一。有的版本VG名叫vg_kylin，有的叫centos_vg，有的直接是vg_root，还有用vg0的。如果在实际服务器上按教程里的名字照抄，百分之百会失败。正确的第一步永远是先用vgs或vgdisplay查看实际VG名，然后再执行扩容。

7.3 坑点2：麒麟系统的系统盘分区布局

银河麒麟默认安装时，如果选择自动分区，有时不会把所有空间全部交给LVM。例如系统盘500G，自动分区可能只把前300G的物理卷并入VG，剩下200G作为空闲未分配区，或者留给了某个普通分区。这种情况下你会遇到两种奇怪现象：一是 vgs 显示的VG容量远小于物理盘容量；二是 lsblk 里物理盘下面既有LVM分区也有非LVM分区，但你在fdisk里看到的剩余空间却没法直接加进VG。

解决思路是：如果你确认物理盘上还有未分配的空间，可以用 parted 将其切成新分区，或者直接把整块未分区设备加入VG。最安全的做法是使用 parted 调整分区表，把空闲空间建为LVM分区类型（分区类型代号8e），然后 pvcreate 这个新分区，vgextend 进VG。但如果你不确定盘上有没有重要数据，请先备份。对生产环境上的麒麟机器，我更推荐老老实实另加一块新盘来扩VG，绕开分区表调整的风险。

7.4 麒麟环境里的文件系统类型注意问题

银河麒麟V10默认根文件系统通常是ext4，但也有定制版使用xfs。执行扩容前先df -T /确认。如果根是xfs且执行resize2fs会直接报错，必须改成xfs_growfs /。反过来说如果根是 ext4 而对xfs用xfs_growfs也会报错。这个错误提示对新手来说不太直观，但排查路径很简单——先看文件系统类型，再决定命令。

最后一个提醒：银河麒麟的软件源在国内镜像可用，但在某些内网环境可能没有开放yum源。如果连 lvm2 工具都装不上（pvcreate 这类命令会缺失），先从本地ISO挂载配一个本地源，再安装lvm2。我在内网环境遇到过很多次"命令不存在的报错"，最后都是因为没配源导致的，和LVM本身没有半点关系。

8. LVM的边界：哪些场景不适合，以及我的运维经验清单

聊完各种成功的扩容，也得说说LVM的边界。任何工具都有不适合的场景，盲目上LVM同样会吃苦头。

8.1 三个不建议用LVM的场景

第一个场景是数据库裸设备或者要求极致低延迟存储的物理机环境。LVM多了一层映射，虽然现代内核里设备映射代价极小，但延迟敏感的工作负载通常会绕过文件系统和逻辑卷，直接把整个磁盘或者分区交给数据库管理。这个时候LVM引入的不确定性反而成了团队不愿承受的风险。

第二个场景是单块盘、单分区、且容量几乎不会再变动的小机器。比如一台只有一块40G盘、只跑一个静态网站的轻量服务器，没有扩容需求，也没有快照需求，直接 ext4 格式化分区即可，多一层LVM反而增加管理复杂度。

第三个场景是超大规模集群统一存储管理。几百台机器的磁盘如果都用LVM，你又没有一个完善的配置管理工具（如ansible脚本），手动维护会变得非常痛苦。大部分集群场景下，直接用云盘或者分布式存储，比每台机器单独折腾LVM更合理。

8.2 LVM快照的正确用法

LVM的原生快照功能很多人没用过，实属浪费。快照的原理是写时复制（COW）：创建快照后，原LV上被修改的数据块会被复制到快照区域，快照始终保持某个时间点的状态。创建命令很简单：

lvcreate -L 20G -s -n snap_root /dev/vg_root/lv_root

这会在 vg_root 里创建一个20G的快照卷 snap_root。生产环境大有好处的场景是升级软件包、改配置之前拍一个快照，万一出问题可以秒级回滚。注意快照卷不能无限膨胀，快照空间满了之后会自动失效，所以快照大小要大于未来一段时间内原LV的写入量。不想用了直接lvremove移除快照卷，不影响原LV。

8.3 我在实际运维中的三点体会

第一点，监控VG剩余空间比监控某个文件系统使用率更有前瞻意义。你可以给每个文件系统定告警阈值，但VG剩余空间才是扩容决策的直接参考。vgs 的剩余空间见底时，即使当前所有LV都还没满，也要未雨绸缪准备加盘了。

第二点，使用LVM后，系统盘和数据盘到底要不要放到同一个VG里要慎重。如果只有一块盘，没得选，根和数据共用VG。如果有多块盘，我倾向于系统盘独立VG，数据盘独立VG。这样即使数据盘操作失误，系统引导不会受影响；相反系统盘容量告急，也不至于牵连数据盘业务。之前不少人图省事把所有盘全并入一个VG，结果某次在数据盘上做pvremove时差点把根卷空间卷进去，冷汗都下来了。

第三点，所有LVM相关操作默认先开一个screen或tmux会话。扩容操作偶尔会出现网络断连终端卡死的情况，如果操作在tmux里，断线重连后操作现场还在，不会出现"lvextend执行到一半不知道成功没有"的尴尬。我在云服务器上操作时都养成了这个习惯，算是一个成本极低但受益无穷的小技巧。