LVM 逻辑卷入门：为什么生产环境喜欢它

LVM 在物理磁盘和文件系统之间加了一层可调配的中间层，逻辑卷就住在这一层里。能在线扩容、能跨盘聚合、能拍快照，生产环境偏爱它的原因全在这三件事上。术语先交代：PV（Physical Volume）物理卷、VG（Volume Group）卷组、LV（Logical Volume）逻辑卷。 三层结构 物理卷 PV：把整块盘或分区注册进来，pvcreate /dev/vdb1； 卷组 VG：把物理卷攒成一个资源池，vgcreate data_vg /dev/vdb1； 逻辑卷 LV：从池里切出卷来用，lvcreate -n app_lv -L 200G data_vg。 之后正常格式化挂载：mkfs.xfs /dev/data_vg/app_lv，再写进 /etc/fstab。磁盘容量先汇进池子、再从池子里分配，这个模型是理解一切命令的基础。三层各自的现状，pvs、vgs、lvs 三条命令一眼看全；vgrename、lvrename 改名也是一条命令的事，工具链一脉相承，会了创建，管理顺手就记住。拆除要按反序来：lvremove 删逻辑卷、vgremove 删卷组、pvremove 退物理卷，顺序颠倒会报设备占用；卷还挂载着先 umount，被进程读写时强行删除是数据事故的常见起点。 在线扩容示例 data_vg 快用完了，挂一块新盘 vdc 进来：pvcreate /dev/vdc && vgextend data_vg /dev/vdc，然后 lvextend -L +500G /dev/data_vg/app_lv -r。末尾的 -r 让文件系统跟着一起扩，ext4 和 xfs 都认；不想算数字，lvextend -r -l +100%FREE /dev/data_vg/app_lv 把剩余空间一次吃满。全程挂载不卸、业务不停，这是普通分区做不到的。 快照，一笔带过但值得知道 升级前拍一个：lvcreate -s -n app_snap -L 10G data_vg/app_lv。改动有问题，lvconvert --merge /dev/data_vg/app_snap 回滚。快照占用的是写入差量，预留空间要按预期改动量来给。名字里带日期是个好习惯，快照一多，靠名字就能对上时间。lvs 输出里的 Snap% 字段显示快照空间的消耗，长期接近满格就要扩快照或者及时合并，写满的快照会失效，等于白拍。数据库场景对它依赖更深：锁表拷贝文件容易拖垮业务，LVM 快照瞬间定格，备份程序对着快照慢慢拷，原库毫无感知。 顺带认一下路径：/dev/data_vg/app_lv 是 /dev/mapper/data_vg-app_lv 的缩写，两者是同一个设备，fstab 里写哪个都对。 什么时候不必上 LVM 单盘小机器、业务简单，直接分区挂载更省心；数据盘多、跑数据库、需要快照回滚能力的场景，LVM 的复杂度才花得值。上不上先想清楚一件事：磁盘层的灵活，要拿一层抽象和几条新命令来换。