★ FEATURED ARTICLE 1. 从一次磁盘告警说起前几天处理了一台生产服务器的磁盘告警应用日志把/home所在分区塞得只剩 3% 空间。当时那台机器当初是用传统分区方式装的系统/home单独划了一个分区结果现在想扩容就很尴尬——相邻空间没预留要么把数据拷出来重做分区要么只能删日志腾空间。折腾了大半天最后虽然解决了但我心里很清楚如果当初用的是 LVM这个扩容动作十分钟就能搞定。其实这就是我写这篇内容的动机。磁盘管理是每个 Linux 用记都绕不开的基本功而 LVM逻辑卷管理则是在传统分区之上提供了一层灵活的管理抽象让你能在线扩容、缩容、做快照再也不用为当初分区拍脑袋买单。这篇文章从零开始把磁盘分区底层概念、LVM 的三层架构、从初始化到挂载的完整实操、扩容缩容的细节到我踩过的坑和排查思路全部过一遍。适合刚入门的同学建立完整认知也适合已经能用但总差点火候的老手查漏补缺。2. 磁盘管理的底层认知这层不搞懂LVM 就是空中楼阁2.1 从物理磁盘到可挂载分区任何存储管理起点都是物理磁盘。一块/dev/sda看起来是个设备文件但其实它就是一块搬回家还没装修的空地。要让它能被系统使用必须经过两步分区和格式化。分区的作用有两点一是把磁盘按用途切开比如系统盘、数据盘、交换分区分开管理二是给操作系统一个明确的边界知道哪里是哪里。格式化的作用则是建立文件系统比如 ext4、XFS 这些让数据能以文件而不是裸字节的形式存取。这俩顺序不能反也缺一不可。分区表格式常见的有两种MBR 和 GPT。MBR 是老大爷级别了最开始只支持 4 个主分区容量上限在 2TB 左右再大的磁盘就得靠 GPT。GPT 是新一代标准分区数量基本不受限默认 128 个单分区容量能到 ZB 级别。2025 年如果你还在 MBR 上新建超过 2TB 的数据盘妥妥被坑。2.2 分区工具怎么选fdisk、parted、gdisk分区工具有三个常见选择我的使用习惯是这样的fdisk老牌经典交互式界面适合小磁盘和 MBR 分区表场景。但碰上 GPT 或 2TB 以上磁盘fdisk 旧版本就不太行了新版 fdisk 也已经支持 GPT。gdiskfdisk 的 GPT 版本操作习惯类似适合新建 GPT 分区表。parted命令式操作既支持 MBR 也支持 GPT还能做非交互脚本化分区是自动化场景的首选。现场实操中如果只是偶尔分个盘fdisk/gdisk 够用如果机器多、要重复操作建议直接上 parted把命令写到脚本里一次执行完。2.3 文件系统怎么选ext4 还是 XFS分区格式化那一步文件系统的选择很关键。当前 Linux 主流的两款是 ext4 和 XFS。ext4 是老牌文件系统稳定、可在线缩容虽然也不建议经常缩特点是兼容性好各种工具成熟。XFS 是 Red Hat 系发行版默认性能强尤其大文件和大目录场景更胜一筹但有个关键限制XFS 不支持缩容。这在 LVM 场景下影响巨大——如果你的数据卷用的是 XFS那扩容没问题但缩容完全没戏除非重新建文件系统。我的建议普通场景数据变化不大用 ext4 更灵活追求性能和更大的带宽吞吐用 XFS 但要提前规划好容量别指望能缩。注意如果一开始就打算用 LVM 管理数据盘分区这步别直接格式化要留出空间给 LVM 创建物理卷。很多新手踩的第一个坑就是分区完了顺手 mkfs然后把整个设备又拿去建 PV结果系统报已有文件系统。3. LVM 核心架构三层结构的本质其实就一句话3.1 为什么需要 LVM传统分区的三个死穴没有 LVM 之前传统分区的痛苦是刻骨铭心的。分区大小定下来就是定下来数据放满了想扩要么找相邻未分配空间通常没有要么备份重做风险高、停机时间不可控。分区结构调整也极其繁琐删分区再建分区数据全没了。更郁闷的是多块磁盘想合并成一个存储池传统分区根本做不到。LVM 解决的问题恰好就是这三点动态扩容缩容、多磁盘聚合、在线调整。它的设计思路和内存管理中的虚拟内存有点像——在物理资源和最终使用者之间加一层抽象使用者在抽象层工作底层怎么变不感知。磁盘管理里的虚拟化这就是了。3.2 PV、VG、LV 与 PE、LELVM 架构分三层PV物理卷把分区或整块磁盘初始化成 LVM 能识别的物理卷。相当于把土地圈成一块一块的统建房土地。VG卷组多个 PV 汇合成一个 VG相当于把几块土地合并成一个开发区在建楼之前统一规划。LV逻辑卷从 VG 里划出的一块实际可格式化的逻辑卷相当于开发区里真正盖起的一栋楼用户住进去挂载使用。对应地还有两个底层概念PE物理扩展块和 LE逻辑扩展块。VG 空间被切成固定大小的 PE默认 4MBLV 由 LE 组成LE 和 PE 是一一对应的映射关系。你看到的扩容缩容本质上就是调整 LE 数量和对应 PE 的映射这比调整物理分区边界要灵活太多。3.3 从一块盘到一个 LV 的完整链路理解链路最好的方式是看一条贯穿始终的数据流物理磁盘 /dev/sdb → 分区 /dev/sdb1可选也可整块盘直接用 → pvcreate 创建 PV → vgcreate 加入 VG → lvcreate 切出 LV → mkfs 格式化 → mount 挂载在这个链路上每层都有对应的查询命令lsblk看设备结构pvs看 PVvgs看 VGlvs看 LV。可以先把这条链路背下后面实操全是在这条链上做文章。4. LVM 配置全流程实操从初始化到开机自动挂载4.1 环境准备新磁盘的识别与确认实操前先确认物理磁盘已被系统识别。我习惯先跑一下lsblk再跑fdisk -l或parted -l确认容量和盘符。# 查看磁盘结构 lsblk # 查看完整磁盘信息包括容量、扇区、分区表类型 fdisk -l如果是虚拟机或云主机新挂的数据盘经常遇到盘符不出现的情况。别急先看dmesg | tail看看内核是否检测到新设备再检查云控制台/虚拟化管理界面确认磁盘是否真的挂上了。如果磁盘是热插拔的且内核没识别可以重启或扫描 SCSI 总线# 重新扫描 SCSI 主机总线服务器场景常用 for host in /sys/class/scsi_host/host*; do echo - - - $host/scan; done4.2 分区还是不分整盘直通 PV vs 分区建 PV创建 PV 前有个经典问题直接把整块磁盘pvcreate还是先分区再pvcreate整盘直通的好处是省事、方便后续对多块盘统一管理坏处是一旦后面想做 RAID、换盘替换缺少分区表这层保护某些老旧工具识别起来不直观。分区建 PV 的好处是分区边界清晰、可以在分区层叠加其他元数据缺点是多个 PV 时管理维度多了一层。我个人建议新数据盘要么整盘直通要么分一个占用全盘的单分区。不要做成两个分区一个 PV 一个备用这种结构LVM 的意义就是让你不用在物理层预留犄角旮旯反而违背初衷。本次演示用整盘直通方式生产环境如果习惯分区方式多加一个pvcreate /dev/sdb1的步骤即可。4.3 创建 PV/VG/LV 完整命令演示这里以/dev/sdb这块 100GB 的空盘为例目标是在上面创建一个 50GB 的 LV挂载到/data。第一步初始化 PV# 将 /dev/sdb 创建为物理卷 pvcreate /dev/sdb # 验证 pvs pvdisplaypvdisplay会更详细地显示 PV 的 UUID、VG 归属、PE 大小和 PV 总大小。看到 PV Status available 就说明初始化成功。第二步创建 VG。这里就涉及命名规范了——VG 名建议能体现用途比如vg_data、vg_system。不要用默认的VolGroup00这种名字机器多了你会后悔# 把 /dev/sdb 加入到名为 vg_data 的卷组 vgcreate vg_data /dev/sdb # 验证 vgs vgdisplayvgdisplay的Free PE / Size字段尤其重要它是后面扩容时判断卷组剩余空间和分配 PE 的依据。第三步创建 LV# 从 vg_data 中切出一个名为 lv_data、大小为 50GB 的逻辑卷 lvcreate -L 50G -n lv_data vg_data # 验证 lvs lvdisplay也可以用-l 100%FREE的写法把 VG 剩余空间全部给某一个 LV-l后跟 PE 数量也可以精确控制。我一般用-L指定容量更直观。提示如果不指定 PE 大小默认 4MB。除非特别小的存储池需要调小 PE调小 PE 对碎片控制有帮助否则保持默认就好。第四步格式化并挂载# 格式化文件系统选 xfs 或 ext4这里用 xfs 演示 mkfs.xfs /dev/vg_data/lv_data # 创建挂载点并挂载 mkdir -p /data mount /dev/vg_data/lv_data /data # 验证 df -hT /data注意 LVM 设备路径是两个常见的写法/dev/vg_data/lv_data或者/dev/mapper/vg_data-lv_data。二者指向同一个设备只是一个是 LVM 自建的目录结构一个是基于/dev/mapper/的映射链。4.4 开机自动挂载UUID 与 /etc/fstab 的正确姿势这一步很多人只做到 mount重启后又傻眼。必须把挂载信息写进/etc/fstab# 拿到逻辑卷的 UUID blkid /dev/vg_data/lv_data然后编辑/etc/fstab加一行UUIDxxxx-xxxx-xxxx-xxxx /data xfs defaults 0 0有两点特别重要。一是defaults里的挂载参数如果文件系统是 XFS可以加上nofail这样万一设备没出现开机也不会卡在等待挂载上直接进入紧急模式。二是不要直接写/dev/vg_data/lv_data这种设备路径——虽然现在 LVM 路径稳定但系统里多块盘、设备名变化时用 UUID 引用最保险。写完 fstab 后一定要执行mount -a验证如果这条命令报错立即修复否则重启时系统会起不来。5. 扩容实战数据无损在线扩容就这么简单5.1 模拟存储不足场景VX 扩容分几步先造个场景上面创建的 50GB LV 用到 90%现在文件系统空间告急。因为 LV 在卷组里不是一小块分区我们完全可以在不停机状态下给它扩容。扩容分三步走第一步确认 VG 有足够空闲空间。执行vgs看 VG 的VFree字段。如果 VG 还有剩余空间直接走第二步如果 VG 都快满了则需要先对 VG 扩容比如加一块新物理磁盘进入 VG。第二步扩展 LV# 将 lv_data 扩大 20GB lvextend -L 20G /dev/vg_data/lv_data # 或者直接指定到目标大小 lvextend -L 70G /dev/vg_data/lv_data # 如果想把 VG 所有剩余空间都给这个 LV lvextend -l 100%FREE /dev/vg_data/lv_data第三步调整文件系统让扩容生效。这一步太容易漏很多初学者只执行 lvextend然后发现df -h空间没变就是因为忘了文件系统这层。XFS 用xfs_growfsext4 用resize2fs# XFS 在线扩容挂载点参数即可 xfs_growfs /data # ext4 在线扩容挂载点或设备均可 resize2fs /dev/vg_data/lv_data执行完df -h验证。整个过程业务完全不停这就是 LVM 最值钱的能力。5.2 XFS 与 ext4 扩容的差异XFS 和 ext4 在线扩容都能做但有个细节ext4 的resize2fs在设备正在挂载时也能执行XFS 则需要通过xfs_growfs指向挂载点来操作。虽然效果一样但命令参数有区别别搞混。另外一个扩容常见场景是加了块新盘/dev/sdc想把它并入已有的 VG 给现有 LV 扩容。步骤是# 初始化新物理卷 pvcreate /dev/sdc # 把新 PV 加进 vg_data vgextend vg_data /dev/sdc # 然后再 lvextend xfs_growfs/resize2fs这就是 LVM 聚合多块磁盘的威力——之前 100GB 的单盘再加两块 200GB 的盘存储池直接变 500GB业务侧完全无感。5.3 扩容过程中的避坑经验有个坑我记忆深刻有一次给某个 XFS 逻辑卷扩容lvextend xfs_growfs 都执行了但df显示容量没有变化。排查了一会儿发现是xfs_growfs用了设备路径而挂载参数限制了自动扩展。正确做法是XFS 扩容执行xfs_growfs /挂载点不要用设备路径。更准确地说xfs_growfs后面跟的是挂载点或者设备文件两者都能用但如果挂载点有pquota、prjquota这类限制扩容就会受影响。所以生产环境执行完扩容一定跑xfs_growfs之后马上看df -h别想当然认为命令成功了容量就上去了。还有一点扩容时最好顺手做一个lvdisplay记录下 LV 的当前大小万一操作过程中断能快速知道扩展了没有、扩展了多少。这个习惯能省很多排查时间。6. 缩容实操非必要不缩容有时也逃不掉6.1 缩容的前置条件文件系统被冻结前文提到 XFS 不支持缩容这是 XFS 设计的硬限制。而 ext4 虽然支持在线缩容但风险远高于扩容。我个人的原则是非必要绝不缩容。如果真的需要缩也必须先卸载文件系统再操作绝不能在线缩。为什么不能在线缩缩容操作本质是移动文件系统数据和元数据在线上进行时如果有进程正在写磁盘数据会瞬间损坏。哪怕 ext4 有些版本能在线缩我也不敢冒这个险。正确姿势# 卸载文件系统前先停止对挂载点的所有写入服务 umount /data # 检查文件系统确保无错误 e2fsck -f /dev/vg_data/lv_data # 缩容文件系统到 40GB必须先缩文件系统再缩 LV resize2fs /dev/vg_data/lv_data 40G # 缩 LV lvreduce -L 40G /dev/vg_data/lv_data # 重新挂载 mount /dev/vg_data/lv_data /data顺序至关重要一定是先缩文件系统后缩 LV。如果先缩了 LV 再缩文件系统数据可能已经损坏了。这跟扩容完全反着来——扩容是先扩逻辑卷再扩文件系统。6.2 缩容场景哪些情况才值得做实战中我很少主动缩容但确实遇到过一个值得缩的场景某监控平台数据保留周期从 90 天改成 30 天数据量骤降占用从 80% 掉到 20%同时新项目又急需一块卷。这时候直接把这块卷缩下来把空间让出去比重新规划存储要高效得多。但即便如此我也先在测试环境完整演练了几遍确认缩容流程无误后才挑低峰期在停机维护窗口操作。缩容前务必备份关键数据。哪怕流程再熟练设备故障和操作失误都是概率事件。LVM 快照或者常规备份都行关键是有一条兜底的路。6.3 关于ext4 缩容后变小不回来的问题有个常见疑问缩容后如果发现空间不够了能不能再扩回去答案是可以扩回来比缩容器要安全得多。resize2fs在缩的基础上再扩数据只会增加不会移动已有数据块风险相对低。但要想清楚文件系统的容量和 LV 容量是两个维度扩文件系统之前必须先把 LV 扩了先扩 LV 再扩文件系统否则文件系统并不知道底层空间变了。这里也提醒一句缩容后文件系统可能产生碎片最好观察一段时间的性能。ext4 下可以定期e2fsck检查必要时做碎片整理。7. 快照备份瞬间一致状态LVM 的隐藏大招7.1 快照原理Copy-on-Write 不是复制一份LVM 快照的底层机制叫 CoW写时复制。很多人第一次看到快照以为是一份数据的完整备份其实不是。创建快照瞬间并不复制数据只是把原来的数据块标记为只读保留。当后续有写入发生时原数据块在覆盖前先被复制到快照区域然后再写入新数据。这样快照里保存的是创建那一刻的数据状态。这意味着两件事第一快照创建是瞬间完成的几秒级甚至亚秒级无论数据卷多大第二快照占用空间是逐步增长的——如果没有数据变更快照几乎不占空间数据变更越多快照占用越大最终快照空间满了就失效。7.2 快照的创建、挂载与恢复创建快照的命令核心是lvcreate -s。比如给/dev/vg_data/lv_data建一个 10GB 的快照# 创建快照卷 lv_snap lvcreate -L 10G -s -n lv_snap /dev/vg_data/lv_data # 查看快照状态 lvs -a快照建出来后可以像普通 LV 一样挂载做只读检查mkdir -p /mnt/snapshot mount -o ro /dev/vg_data/lv_snap /mnt/snapshot检查完不要忘记卸载umount /mnt/snapshot如果实际数据损坏需要恢复方式也直接但注意恢复过程会覆盖当前数据和用备份恢复一样具备破坏性# 严格来说官方更推荐用快照导出文件而不是原地回滚 # 原地回滚方式是 lvconvert --merge /dev/vg_data/lv_snaplvconvert --merge会把快照里保存的数据状态合并回原 LV。这个过程会中断对原 LV 的访问所以必须先卸载原 LV 再合并而且一旦合并没有后悔药。我在生产环境中更愿意用快照挂载后 tar/cp 导出数据的方式这样新数据还能保留不至于因为一次合并把之后的新写入数据全部丢掉。7.3 快照的两个硬教训第一个教训快照容量给太小会很快失效。假设数据卷每天变更 5GB 数据快照只给 2GB 空间大概率一晚上就爆。快照一旦写满会变成invalid状态数据依然安全原卷不受影响但快照失去恢复作用此时必须删除重建快照。所以快照容量要根据数据变化率给足一般至少 10%~20% 原卷容量起步变化猛的数据建议 30% 以上还要给监控告警。第二个教训快照不是备份。快照和原卷在同一存储池里如果整块磁盘损坏、或者误执行导致 VG 被破坏快照一样玩完。真正的备份必须带去重/异地/另外介质快照只是低成本的临时回滚保险。几年里见过太多人把快照当备份用最后数据全没这个认知一定要纠正过来。8. 常见问题与排查技巧实录让人头疼的五个场景8.1 重启后挂载不上fstab 写错后的自救这是出镜率第一的问题。症状开机进入紧急模式或者挂载失败。原因多半是 fstab 里的 UUID 写错了、设备路径变了、或者文件系统类型填错。排查思路先看系统日志journalctl -xb里会列出具体挂载失败的原因。进入紧急模式后用mount -a尝试加载所有 fstab 项如果报错用vi修复 fstab注释掉出问题的行然后mount -a验证。我习惯在任何 fstab 改动后都在重启前执行mount -a没问题再重启这是成本最低的一道保险。8.2 pvcreate 提示设备被占用或已有文件系统新数据盘如果之前被用过比如做过 RAID 或文件系统pvcreate时会报错。解决方案是添加-f强制创建但强制是把双刃剑——执行前必须确认这块盘没有需要保留的数据# 确认盘上没有需要的文件系统 wipefs -n /dev/sdb # 强制初始化 PV pvcreate -f /dev/sdbwipefs -n是只显示不执行安全真正擦除用wipefs -a /dev/sdb执行前想清楚。8.3 卷组空间够但 lvextend 报错 No space leftLV 扩不动先vgs看卷组的 VFree再看是不是 PE 大小导致剩余空间小于一个 PE还有一种情况是 VG 内碎片化严重但不是通常说的碎片而是 PV 过多且每个 PV 空间分布不均导致无法在一个 PV 上连续分配。但 LVM 本质不要求连续所以最常见的还是 PE 数量问题。解决办法vgdisplay看Free PE / Size如果确实只剩一点点但不够分配就vgextend加盘或者把-L 20G改成-L 略小于剩余空间。8.4 误删 VG 或 LV 的恢复最坏的情况vgremove误删了一个卷组或者lvremove删了逻辑卷。很多人当场崩溃。但 LVM 元数据在 PV 上是保留的只是头部元数据被毁了一部分。如果是误删 LV 且没有重启某些情况下可以用vgcfgrestore尝试从/etc/lvm/backup恢复元数据如果是误删 VG也可以vgcfgrestore恢复。但成功率受很多因素影响比如是否立即重启、元数据备份是否最新。我的建议是第一时间停机上对磁盘的写操作调出/etc/lvm/archive和/etc/lvm/backup目录下最近的备份仔细阅读后执行恢复。这类操作很高级生产环境最好让有经验的人来操作别自己乱试。8.5 逻辑卷无法移除设备被占用lvremove时经常遇到 device busy 或者无法移除。原因通常是 LV 还处于挂载状态或者有进程在使用它。解决办法# 找到谁在用 lsof /data fuser -vm /data # 先卸载 umount /data # 如果卸载时报 target is busy先杀掉占用进程 fuser -km /data还有一种特殊情况是我常踩的某目录使用了逻辑卷但其他进程把工作目录放在了里面导致umount显示 busy。这时候fuser -v能看到具体进程处理完再卸载就顺了。9. 工具与命令速查常用的都在这里9.1 查询类命令# 查看块设备树和容量 lsblk # 查看物理卷信息 pvs pvdisplay # 查看卷组信息 vgs vgdisplay # 查看逻辑卷信息 lvs -a lvdisplay # 查看挂载和设备 UUID df -hT blkid建议把这些命令形成肌肉记忆。遇到任何存储问题第一步先lsblkdf -hT看全貌再逐层pvs/vgs/lvs定位。不要一上来就猜测。9.2 创建/修改类命令# 创建 PV/VG/LV pvcreate /dev/sdb vgcreate vg_data /dev/sdb lvcreate -L 50G -n lv_data vg_data # 扩容 lvextend -L 20G /dev/vg_data/lv_data xfs_growfs /data resize2fs /dev/vg_data/lv_data # 缩容ext4必须严格按顺序 umount /data e2fsck -f /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data 40G lvreduce -L 40G /dev/vg_data/lv_data mount /dev/vg_data/lv_data /data # 快照 lvcreate -L 10G -s -n lv_snap /dev/vg_data/lv_data9.3 巡检建议我平时怎么监控存储生产服务器多了靠人肉看df不现实。我习惯做两层监控一层是基础容量告警对每个挂载点做阈值检测空间使用率超过 80% 就开告警超过 90% 立刻介入另一层是 LVM 状态巡检重点看 VG 剩余空间VFree防止出现LV 扩容时卷组没空间的尴尬。如果你的环境里 LVM 用得频繁建议建立一张存储规划表记录每台机器的 VG 名称、LV 数量和用途、文件系统类型、扩容历史。这个表格在故障排查和容量规划时有奇效。我的几个实操体会想用几句话做最后的收尾——不是总结而是几个真实的工具感。第一LVM 最大的价值不是花哨的功能而是给人留了后悔药。传统分区一旦定下后面改就是在刀尖上跳舞LVM 虽然也是分区那一层的抽象但它把重新规划的成本降到了分钟级。吃过亏的人才能真正理解这一点。第二扩容记得三步走先看 VG 空间 → 扩展 LV → 扩展文件系统。这个顺序不能乱漏了最后一步最常见也是最容易被忽略的。我见过太多同事扩完 LV 后盯着 df 发呆半天最后才想起忘了xfs_growfs。第三做任何涉及 LVM 的破坏性操作前先备份元数据。vgcfgbackup这个命令很多人根本不知道但它关键时刻能救命。把它加进操作前的固定动作就像开车系安全带一样自然。如果让我只说一个建议那就是从今天开始凡是新建的文件系统卷都先用 LVM 规划好。哪怕一开始只需要一个 50GB 卷也让它生在 LVM 里——因为你永远不知道半年后这个卷会不会变成 500GB而到那时LVM 会替你感谢当初那个多花了五分钟做规划的自己。
阅读完成 · 觉得有帮助？
