从裸盘到LVM：Linux逻辑卷管理完整实操指南

2. 核心实操记录从裸盘到 LVM 的完整链路2.1 前置准备摸清服务器磁盘现状接手一台新服务器或者准备给现有服务器做扩容时我从来不会直接上来就敲 LVM 命令而是先把磁盘现状摸清楚。这一步看似基础实际上能帮你避开后面 80% 的坑。最常用的就是lsblk、blkid、df -hT这三个命令配合使用基本就能把一台服务器的存储情况看透。lsblk输出的树形结构最直观它会把物理磁盘、分区、LVM 逻辑卷以及挂载点的关系全部展现出来。比如你在输入lsblk之后看到一个sda下面挂着sda1、sda2而sda2下面又出现vg-root、vg-swap这种带lvm标记的子项那就说明系统盘已经用上了 LVM 管理。这个信息很重要因为 RHEL、CentOS、Rocky Linux 这类发行版在默认安装时系统盘几乎都是 LVM 布局。lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 40G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 39G 0 part ├─rl-root 253:0 0 35G 0 lvm / └─rl-swap 253:1 0 4G 0 lvm [SWAP] sdb 8:16 0 20G 0 disk这个输出里sda是系统盘rl-root和rl-swap是安装系统时自动创建的 LVM 逻辑卷sdb是我为了演示新加的一块 20G 空盘目前还没有任何分区和文件系统。df -hT则负责看真实的使用率blkid用来查看分区的 UUID 和文件系统类型后面写 fstab 的时候会用到。2.2 新建物理卷 PV让磁盘进入 LVM 的世界把一块裸盘变成 LVM 管理的物理卷使用的命令是pvcreate。这里有一个新手容易纠结的问题到底是对整块盘执行pvcreate还是先分区再对分区执行我的经验是如果这块盘是专用于 LVM 的数据盘直接对整块盘pvcreate /dev/sdb就够了省去分区步骤后续扩容和维护都更简洁。但如果你希望这块盘上既有 LVM 分区又有其他用途的分区那就需要先用fdisk或parted创建分区再把分区加入 LVM。pvcreate /dev/sdb命令执行成功后会输出Physical volume /dev/sdb successfully created.。你可以用pvs或pvdisplay查看物理卷的详细信息。pvdisplay会显示 PV 的 PV UUID、总容量、剩余 PE 等数据其中 PEPhysical Extent就是 LVM 分配空间的最小单位默认是 4MiB。这个 PE 大小在创建卷组时就已经定下来了后续所有逻辑卷的大小都是 PE 的整数倍。理解 PE 很重要后面计算扩容容量时你会用到。2.3 创建卷组 VG把散落的磁盘聚合成空间池物理卷创建好之后下一步就是把一个或多个 PV 放进同一个卷组形成一个统一的存储池。命令是vgcreate语法很简单vgcreate vg_data /dev/sdbvg_data是我给卷组起的名字你可以按自己的命名习惯来但建议起得有意义比如vg_data、vg_backup这样后续创建逻辑卷和管理时一眼就能认出用途。如果你想把多块盘放进同一个 VG直接在命令后面跟上所有 PV 路径即可vgcreate vg_data /dev/sdb /dev/sdc创建完成后用vgs查看卷组列表可以看到 VSize卷组总大小和 VFree剩余可用空间。这里有个细节卷组创建时默认的 PE 大小是 4MiB如果你的存储池容量很大比如几十 TB可以考虑在创建时通过-s 16M或-s 32M调大 PE 大小这样可以减少元数据开销。但大多数中小规模场景默认 4MiB 完全够用。2.4 创建逻辑卷 LV从池子里切出可用的虚拟分区卷组有了空间池子也有了接下来就是从池子里切出实际能用的逻辑卷。命令是lvcreate最常用的参数是-L指定大小-n指定名称lvcreate -L 10G -n lv_data vg_data这条命令从vg_data这个卷组里切出一块 10G 的逻辑卷名字叫lv_data。创建完成后逻辑卷的路径就是/dev/vg_data/lv_data。你也可以用-l参数按 PE 数量来指定大小比如-l 100%FREE表示把卷组剩余空间全部用来创建逻辑卷这在某些自动化场景下很好用。创建完 LV 后用lvs或lvdisplay查看逻辑卷的详细信息。注意LV 此时只是一个块设备还没格式化需要通过mkfs写入文件系统才能真正使用mkfs.ext4 /dev/vg_data/lv_data如果你用的是 Rocky Linux 9 或 RHEL 9默认文件系统推荐 xfs那也可以用mkfs.xfs。到底选 ext4 还是 xfs这个我会在下面专门分析。2.5 挂载并写入 fstab让数据卷开机自动生效格式化之后就是常规的挂载操作。创建一个挂载点目录然后挂载mkdir -p /data mount /dev/vg_data/lv_data /data df -hT /data此刻/data目录已经可以正常读写。但你重启服务器之后这个挂载关系就丢了所以还需要写进/etc/fstab实现开机自动挂载。我推荐用 UUID 而不是设备路径来写 fstab因为设备路径在系统启动过程中可能存在顺序变化的风险比如/dev/sdb和/dev/sdc顺序错乱而 UUID 是永久稳定的。先获取 UUIDblkid /dev/vg_data/lv_data然后把下面这一行追加到/etc/fstab末尾UUID你的UUID号 /data ext4 defaults 0 2写完之后强烈建议先执行mount -a验证一下配置没写错再考虑重启。如果 fstab 写错了服务器可能直接起不来那种紧急模式体验极差我后面会在故障排查部分专门讲怎么处理。2.6 ext4 还是 xfs文件系统选型决定扩容策略同样是格式化mkfs.ext4和mkfs.xfs的后续操作路径差异很大我在实际工作中体会到这个选择会直接影响你后面扩容缩容的手感所以单独拿出来说。ext4 的最大优势是支持在线缩容。虽然缩容操作比例扩容要谨慎得多必须先缩文件系统再缩 LV但至少给你留了一条后路。xfs 则完全不支持缩容只能扩不能缩。如果你的业务场景是数据库、文件存储这种容量规划经常要调整的我建议用 ext4。如果你更看重超大文件和高并发写入性能或者你用的是 Rocky Linux 9 这种默认推荐 xfs 的系统那用 xfs 也没问题只要你的容量规划留有足够余量就行。从扩容操作来看ext4 使用resize2fs在线扩展文件系统xfs 使用xfs_growfs扩展。两者的区别在后面的扩容章节我会详细演示。这里你先记住一个结论没有特殊需求时我个人更偏向 ext4因为它的工具链更通用排错资源也更丰富。3. 实操演示扩容、缩容和快照3.1 在线扩容逻辑卷从 10G 扩到 15G现在假设/data空间不够了业务告警说使用率已经到 95%你需要在业务无感知的情况下把空间扩大。LVM 在线扩容的操作顺序是先扩 LV再扩文件系统。如果顺序反了文件系统不会自动感知底层块设备的变大你重启之后可能发现空间并没有真正变多。扩容 LV 用lvextend有两种指定方式效果完全不同lvextend -L 15G /dev/vg_data/lv_data # 直接把 LV 扩展到 15G lvextend -L 5G /dev/vg_data/lv_data # 在现有 10G 基础上增加 5G-L 15G是把最终大小设置为 15G-L 5G是增加 5G。初学的时候很容易把这两个搞混我建议养成习惯扩多少就明确用号表示增量这样即使你记不清当前 LV 多大也不会扩出一个超过预期的容量。执行完后用lvs确认 LV 大小已经是 15G。接下来扩展文件系统。这一步有个关键差异要记住ext4 用resize2fs并指定设备路径xfs 用xfs_growfs并指定挂载点路径# ext4 resize2fs /dev/vg_data/lv_data # xfs xfs_growfs /data执行完文件系统扩展后再df -h /data就能看到容量已经刷新为 15G。整个过程不需要卸载挂载点业务无感。3.2 缩容逻辑卷风险最高的 LVM 操作缩容比扩容复杂得多因为它涉及数据迁移和边界拆除顺序和扩容完全相反必须先缩文件系统再缩 LV。而且缩容操作对 ext4 相对友好对 xfs 则完全不支持。我在生产环境里除非非常必要否则都不会主动做缩容尤其是有重要业务数据在跑的时候。如果你确实要缩而且文件系统是 ext4基本流程如下。先把目标缩到 12G 为例第一步是卸载挂载点避免文件系统在使用中被合并umount /data然后强制检查文件系统确保没有损坏和未释放的块e2fsck -f /dev/vg_data/lv_data接着把文件系统缩小到目标大小。这里有个细节resize2fs缩文件系统时要把目标大小设置为 LV 的目标大小相同或略小因为后面还有一步要把 LV 缩到同样的大小如果文件系统比 LV 还大就会出问题resize2fs /dev/vg_data/lv_data 12G最后缩小 LV 到同样大小lvreduce -L 12G /dev/vg_data/lv_data重新挂载并验证mount /dev/vg_data/lv_data /data df -hT /data缩容过程中的任何一个步骤出错都很危险尤其是lvreduce一旦缩到比文件系统还小数据直接损坏。所以我强烈建议缩容前先做完整备份缩容时两块目标大小务必对齐。如果你用的是 xfs直接放弃缩容这个念头xfs 的设计就是只支持扩容。3.3 快照掉坑前必看的安全网LVM 快照是我最喜欢的功能之一它能在瞬间生成一个逻辑卷的冻结副本用于升级前的安全网、备份前的一致性快照等场景。它的原理是写时复制Copy-on-WriteCOW创建快照时并不复制所有数据而是标记当前数据为只读状态后续对原卷的新写入会先复制到快照区域从而保证快照里保存的是创建时刻的数据。创建快照的命令很简短lvcreate -L 2G -s -n lv_data_snap /dev/vg_data/lv_data这条命令基于lv_data创建一个 2G 大小的快照卷名字叫lv_data_snap。注意-L 2G不是快照的最终大小而是快照的增量存储空间上限。如果这段时间内原卷变化的数据量超过 2G快照就会写满并自动失效。所以你给快照分配的空间应该参考原卷在快照存续期间的可能写入量而不是原卷总大小。快照的典型使用场景是系统升级前拍一张升级失败后快速回滚。回滚操作是lvconvert --merge /dev/vg_data/lv_data_snap但要注意回滚必须卸载原卷对应挂载点并且快照卷本身也要处于非活动状态。实际执行时系统会提示你用lvchange -an先把卷设为非活动或者干脆建议在重启后通过 initramfs 阶段合并。我在实操中踩过的坑就是lvconvert --merge执行后如果原卷还在挂载命令会失败并提示设备忙处理不好还会让系统进入异常状态。所以我的建议是快照主要用在做可以快速恢复的演练场景比如升级前快照升级出问题后重启时让系统自动合并这样最稳。3.4 跨磁盘扩容把新硬盘加入现有卷组业务增长比预想快一块 20G 的盘又不够用了。你不想迁移数据也不想动现有逻辑卷只想再加一块新盘把容量池变大。LVM 处理这个场景非常优雅。假设新盘是/dev/sdc先初始化 PV再扩展到vg_data卷组pvcreate /dev/sdc vgextend vg_data /dev/sdc执行完vgextend之后vgs就会显示卷组总容量已经增加了新盘的大小。接下来你只需要正常执行lvextend和resize2fs或xfs_growfs即可把新增空间分配到具体逻辑卷上。整个过程完全在线不需要重启不需要迁移数据业务无感。这背后的原理就是 VG 作为空间池的抽象能力多块物理盘被组合成一个大池子逻辑卷从这个池子里按需切分。你不再需要关心数据具体落在哪块物理盘上LVM 会通过 PE 映射自动处理。4. 资源管理经验与故障排查4.1 监控磁盘与逻辑卷使用率提前发现空间瓶颈运维最怕的不是空间满了而是空间满了才发现。我自己维护的服务器都会写一个简单的巡检脚本定期检查根分区、数据分区的使用率。脚本整体不复杂但很实用核心逻辑就是遍历挂载点超过阈值就告警#!/bin/bash threshold80 df -hT | awk NR1 {print $6, $7} | while read fs mountpoint; do usage$(echo $fs | sed s/%//) if [ $usage -gt $threshold ]; then echo $mountpoint usage ${usage}% exceeded threshold ${threshold}% fi done这个脚本挂在 crontab 里每小时跑一次即可。真正生产环境可以接上钉钉机器人或者邮件告警我这里只演示判断逻辑。你还可以用lvs输出的Data%来监控 LVM 逻辑卷的分配率因为有时候文件系统使用率不高但 LV 快满了扩容也得提前做。4.2 VG 耗尽但 PV 有空闲空间PE 分配策略问题有时候你会遇到一个诡异现象vgs显示 VG 还有空闲空间但lvextend却提示 Insufficient free space。这往往是因为 PE 的分配策略限制。LVM 默认的分配策略是contiguous连续也就是说扩容时优先找一段连续的 PE 区间如果 VG 里剩余空间被分割成了多个不连续的小段就无法满足扩容请求。解决办法有两种。一种是在lvextend时加上--alloc anywhere参数允许 LVM 跨非连续区域分配。另一种更优雅的方案是把 VG 里分散的数据整理一下用pvmove将部分 PV 的空间腾出来再进行扩容。说实话这种场景在中小规模服务器里并不常见但一旦遇到排查起来很麻烦。我的经验是优先用anywhere应急业务空闲时再用pvmove整理。4.3 重做文件系统 vs 直接扩容什么时候该推倒重来LVM 扩容虽然简单但并不能解决所有问题。有一次我帮朋友处理一台跑 MySQL 的服务器数据盘是 LVM 上的 ext4空间长期高位运行我直接扩容后文件系统却始终报错e2fsck也查不出大问题。后来我分析了一下这台机器从最初安装到现在经过了多次扩容、缩容、中途断电文件系统里积累了很多历史问题。碰到这种底层文件系统已经用脏了的情况单纯扩容只是把坑填得更大正确做法是备份数据重建逻辑卷重新格式化把数据导回来。虽然听起来工程量大但长远看比在一个不健康的文件系统上不停打补丁更省心。我的判断标准是如果dmesg中出现大量 IO error、ext4 报错日志或者e2fsck需要多次修复才能通过那就应该考虑重建而不是继续扩容。4.4 误删逻辑卷或快照的恢复尝试LVM 有个特性是卷组元数据里记录了 PV、VG、LV 的历史信息所以误删逻辑卷后是有可能通过vgcfgrestore恢复元数据从而找回 LV 的。但这个恢复过程依赖几个前提卷组元数据没有被后续操作覆盖、VG 的备份文件还在/etc/lvm/archive目录里、误删后没有对原卷进行大量写入。我在测试环境里恢复过一次误删的快照卷。具体步骤是先用vgs和pvscan确认当前元数据状态再到/etc/lvm/archive找到误删前的备份文件执行vgcfgrestore把卷组元数据回滚到当时的状态。这个过程说起来不复杂但实际操作有风险如果设备布局和元数据不一致反而会弄得更糟。所以我强调误删 LV 后第一时间停止对相关 PV 的一切写入操作冷静使用vgcfgrestore前最好先在测试环境演练一遍。4.5 磁盘满导致服务异常的排查思路磁盘满的故障有时候并不直接表现为df -h100% 满。比如 inode 耗尽也会导致无法创建新文件此时df -h显示还有空间但df -i却显示 inode 100%。这类问题在大量小文件的场景比如临时目录、邮件队列、容器日志目录经常出现。排查思路是配合df -h和df -i一起看用du -sh /path/*找出大目录用find /path -type f | wc -l估算文件数量。发现 inode 不足时清理小文件、调整文件系统 inode 数量在mkfs时通过-i指定 inode 比例或者干脆迁移到 inode 更多的文件系统类型。这类经验不在 LVM 的核心操作里但却是磁盘管理绕不开的真实问题。5. 总结与项目扩展5.1 常规运维中 LVM 使用的几条铁律第一批服务器上 LVM 之后我给自己定了几条铁律都是踩坑踩出来的体会第一创建 LVM 结构前先规划好命名规范避免后续 VG、LV 名字混乱导致误操作第二扩容和缩容严格区分扩容可以在线缩容必须谨慎确认文件系统类型和当前空间占用第三写入/etc/fstab时用 UUID 而非设备路径规避设备命名漂移第四任何破坏性操作缩容、删除 LV前先做快照或备份。这几条并不高深但能让你少熬很多夜。还有一点值得分享LVM 本身不解决备份问题。快照不是备份镜像同步也不是备份。我在真实项目里见过有人把 LVM 快照当作唯一备份手段结果快照卷因为空间不足失效数据丢了以后无从恢复。逻辑卷只是帮你管理存储结构数据安全还是要靠独立于服务器的备份方案比如专业的备份工具加异地存储这个意识一定要有。5.2 用 LVM 思路管理云硬盘与容器存储LVM 不仅在物理机上有用云服务器也同样适用。云盘的底层虽然也是虚拟化存储但你在操作系统里看到的依然是块设备把数据盘做成 LVM 布局后你可以更灵活地组合不同容量的云盘或者在未来做在线迁移。比如你有一块 100G 云盘不够用再买一块 100G 云盘挂载后pvcreate、vgextend、lvextend三步走业务无感扩容这和物理机的跨盘扩容完全一致。容器场景下Docker 的数据目录如果放在一个独立逻辑卷上后续给容器数据扩容也变得简单。我有一次把 Docker 数据目录从系统盘挪到独立的 LVM 卷上就是为了避免日志和镜像把根分区塞满。具体做法是把/var/lib/docker挂载点独立到一个 LV 上然后在/etc/fstab里保证优先挂载容器服务依赖的底层目录就稳定多了。5.3 项目的下一步演进方向这个 Linux 磁盘管理与 LVM 项目做完之后后续可以从几个方向继续深挖。一个是把磁盘自动化管理脚本化、模板化比如写一套 Ansible Playbook 来自动完成 PV、VG、LV 的创建和扩容批量部署多台服务器时效率提升非常明显。另一个方向是把 LVM 与系统监控联动起来比如通过 Prometheus 采集df和lvs的指标设置告警规则空间使用率超过阈值自动触发扩容脚本真正实现无人值守的容量管理。还有一个值得尝试的方向是结合 LVM 快照做数据库的一致性备份比如在创建快照前后调用数据库的锁表或FLUSH TABLES WITH READ LOCK机制保证文件系统层面的快照跟数据库事务日志对齐这样恢复出来的数据才是完整可用的。这一步能让你在没有商业备份软件的情况下用开源命令组合出接近专业备份的效果。我在这个项目里收获最大的并不是某个命令的熟练程度而是建立起一种存储是资源池、可以随需调整的思维方式。磁盘不再是买回来就固定死的物理分区而是可以灵活调度、在线变化的基础设施。维护 Linux 服务器的人越早接受这个思路越少在深夜因为磁盘告警爬起来。希望这篇分享能帮你在自己的环境里顺利落地 LVM少走一些我当年走过的弯路。