1. 先搞清楚Linux 磁盘管理与 LVM 到底在解决什么问题很多朋友第一次接触 Linux 服务器时前面装系统、配网络都挺顺利结果一到磁盘管理就懵了——明明加了块新硬盘系统里却看不到空间明明根分区快满了却不知道空间去哪了费了半天劲把分区建好第二年要扩容时又得从头再来一遍。这些问题的根源大多不是操作不熟练而是最开始没把磁盘管理当成一件需要“设计”的事情来做尤其是没用上 LVM逻辑卷管理这套成熟的方案。这篇文章是我这些年折腾 Linux 服务器、云主机和虚拟机的实操经验整理不讲 PPT 式的概念只说你怎么一步步把磁盘管好。内容覆盖四个块面Linux 磁盘管理的基础命令和思路、LVM 的原理拆解、从建卷到扩容缩容的完整操作、以及云电脑/服务器场景里重装系统前必须先卸 LVM 数据盘这个容易踩坑的环节。适合刚入行的运维、自己搭服务器和学习 Linux 的开发者也适合准备 Linux 运维面试的人拿来补知识框架。1.1 磁盘管理到底在管什么磁盘管理在 Linux 里不是单一动作而是一条完整链路识别设备、规划分区、创建文件系统、挂载到目录、监控空间使用、最后在容量不足时做扩展或调整。任何一个环节出了问题都会影响业务分区分错了文件数据没地方放挂载路径乱了导致服务起不来fstab 写错直接开机进 emergency mode。这些都是我在实际环境里真真切切遇到过的问题。所以建议你先建立一套自己的“磁盘管理体检流程”新机器到手先 lsblk 看设备布局再用 df -h 看使用率fdisk -l 看物理盘最后用 blkid 看文件系统类型和 UUID。这套流程看起来简单但绝大部分空间故障都能在体检阶段暴露出来。等体检做熟了再进入分区、格式化、挂载、LVM 这些具体操作层面心里就有底气得多。1.2 为什么 LVM 会成为主流方案传统分区有个很扎心的限制分区大小在建好的那一刻就基本固定了。比如你安装系统时给 / 分区分了 100G用了三年满了这时哪怕磁盘上还有另外 200G 的空闲空间只要它们不在同一个分区里就不能直接并入 / 分区。想扩容要么用工具调整分区边界有风险要么把数据迁到新盘上再挂回来中间还要停机。LVM 的思路从根本上改变了这件事。它不让你直接面对物理磁盘分区而是引入了一层“逻辑”抽象先把物理磁盘或分区变成物理卷PV再把多个 PV 合并成一个卷组VG最后从卷组里切出逻辑卷LV来格式化挂载。容量不够时给卷组里加入新盘然后直接扩展逻辑卷就行应用基本上不用停机。你可以把它理解成一个大水池加若干水龙头的模型水池代表卷组水龙头代表逻辑卷水管接进来的水源就是物理磁盘。水池扩容只需要加新水源水龙头的大小随时可调。1.3 哪些场景最需要认真处理 LVM如果你只是在自己电脑上装个 Linux 写代码磁盘管理凑合一下问题不大。但只要有以下特征LVM 基本就是刚需一是服务器上有多块数据盘比如数据库文件、日志、备份各自放一块二是业务容量增长不可预测比如用户的附件上传目录你不知道三个月后会涨到什么量级三是云主机或云电脑环境经常遇到系统盘与数据盘分离、重装系统后还要保留数据盘的情况。我个人强烈建议在装 Linux 服务器时只要安装器支持就尽量把系统盘也做成 LVM。Ubuntu Server 默认安装时就会使用 LVM这个设计不是没道理的就是为了让你以后扩容根分区时不用把机器搞到天翻地覆。后面我会专门讲根分区扩容这是面试和实战里出现频率极高的问题。2. Linux 磁盘管理基础分区、格式化与挂载一步都别跳过2.1 先学会查看磁盘状态不管你是要新加一块盘还是要排查空间告警第一步永远是“看清楚现状”。我惯用的命令顺序是lsblk、df -h、blkid、fdisk -l四个命令各司其职。lsblk 输出的是树状设备结构和 Windows 磁盘管理里的“磁盘 卷”视图很像。它的好处是能一眼看出设备之间的父子关系、分区挂载点、以及磁盘是否完全未使用。举例来说[rootserver ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 100G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 99G 0 part / vdb 252:16 0 500G 0 disk └─vdb1 252:17 0 500G 0 part /data vdc 252:32 0 500G 0 disk从这个输出里能读到的信息vda 是系统盘vdb 已经分区并挂载到 /datavdc 是一块没有分区也没有挂载的全新盘。接下来 df -h 看的是文件系统视角的容量blkid 看的是分区/UUID/文件系统类型fdisk -l 则给出磁盘物理扇区、大小、分区表类型。这四步走完你对这台机器的存储状态心里基本有数了。2.2 分区工具怎么选fdisk、gdisk 与 partedLinux 里做分区最常见的三个工具是 fdisk、gdisk、parted。新手容易问到底该用哪个我的建议是交互式做少量分区用 fdisk管理 GPT 分区表用 gdisk需要脚本化批处理或磁盘大于 2TB 时用 parted。fdisk 是老牌工具新版本已经支持 GPT能处理绝大多数场景。gdisk 是 GPT 专用的交互工具体验和 fdisk 很像。parted 则更灵活一条命令可以做完整分区并指定文件系统类型适合在脚本里自动化操作。记住一个关键动作如果你打算把某个分区加入 LVM建分区时一定要把分区类型标记为 Linux LVM。MBR 格式下类型号是 8eGPT 格式下是 8e00。如果不标记虽然很多时候 pvcreate 也能强行用但分区表语义就是错的后面运维排查时容易带来困扰。2.3 格式化ext4、xfs 还是别的分区建好之后就要写文件系统。Linux 生态里最常碰到的三个文件系统是 ext4、xfs、btrfs。我的选择标准很朴素追求稳定兼容、需要以后能缩容量就用 ext4处理大文件、海量小文件场景优先 xfsbtrfs 功能虽多但我在生产环境里用得极少除非团队里有充分经验否则不建议普通业务尝鲜。格式化命令本身不复杂mkfs.xfs -f /dev/vdb1 mkfs.ext4 -F /dev/vdc1但这里藏着两个高频事故点。第一格式化会彻底销毁分区上的原数据命令执行前务必用 lsblk、blkid 反复确认目标设备没有在用没有残留数据。第二xfs 的在线扩容只能增加不能缩小而 ext4 两者皆可。这个差异在 LVM 场景里进一步放大我会在后面的扩容缩容部分细讲。2.4 挂载与开机自动挂载的正确姿势格式化完成后mount 命令把文件系统挂载到某个目录mkdir /data mount /dev/vdb1 /data但你肯定不希望每次重启都手动挂载一遍所以要写入 /etc/fstab。这里是我见过踩坑最多的地方核心原则是尽量用 UUID 而不是设备名。因为 /dev/vdb 这种名字在系统重启、新增磁盘、云平台热插拔后可能变化而 UUID 是文件系统创建时生成的唯一标识基本不会变。用 blkid 拿到 UUID 后这样写UUIDxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 0写完之后立刻执行 mount -a 做验证如果报错马上改回原样不要让错误的 fstab 留在机器里。很多新手忽略这一步结果一重启系统就卡在 emergency mode只能进救援模式修文件。别问我是怎么知道的。3. LVM 原理拆解PV、VG、LV、PE 其实不难3.1 LVM 分层模型从物理磁盘到逻辑卷LVM 一共四个核心概念物理卷 PV、卷组 VG、逻辑卷 LV、物理扩展块 PE。理解它们之间的关系比死记命令重要得多。物理卷 PV可以是一块磁盘、一个磁盘分区甚至一个 RAID 设备。LVM 会在 PV 头部写入自己的元数据标明这个是 LVM 成员。卷组 VG一个或多个 PV 汇聚起来形成的存储池。卷组里的空间被切成固定大小的数据块这个块就是 PE。物理扩展块 PE默认大小 4MB是 VG 空间分配的基本单位。你创建 LV 时指定大小LVM 会按照 PE 大小取整。逻辑卷 LV从 VG 里划分出来的一段连续空间相当于传统意义上的“分区”。LV 可以格式化文件系统并挂载使用路径一般是 /dev/ 卷组名/逻辑卷名。PE 为什么重要因为它决定了空间分配的“粒度”。默认 4MB 对绝大多数场景都够用但如果磁盘特别大、希望管理更精细可以在创建 VG 时改 PE 大小。代价是 PE 越小LVM 元数据和映射表越大性能与灵活性之间的取舍需要自己把握。3.2 数据是怎么从应用写入磁盘的应用读写文件时数据先落在文件系统层文件系统把数据映射到 LV 上的逻辑地址LVM 再把逻辑地址换算成对应 PE 所在的 PV 物理地址最终通过磁盘驱动写到真实硬件上。这层抽象带来的直接好处是应用根本不用关心数据到底落在哪块物理盘上只要 LV 空间够用就行。它可以跨磁盘存在也可以在某块盘上不连续分布。这也是 LVM 能实现在线扩容和跨盘聚合的根本原因。代价是多了一层映射理论上会引入极小部分额外开销但在现代硬件上几乎无感。3.3 LVM 的优点与限制以及选型判断LVM 的优点非常明确容量灵活调配、支持在线扩容、支持快照、可以把多块不同大小的盘聚合成一个池。但限制也真实存在xfs 文件系统无法在线缩容快照会占用卷组空间且大量写入时性能会下降引入 LVM 后多了一个管理层排错时需要多查一层如果要把数据从一台机器完整搬到另一台LVM 逻辑卷不如普通分区那样“看见盘就能挂”。所以选型时我的判断标准是只要这台机器有“未来容量不确定”的风险就值得上 LVM。如果你只是一块 500G 的盘放点静态资料、永远不扩那传统分区反而更省事。3.4 “重装前需要先从 LVM 卸”——这句话到底在说什么网络热词里专门提到一个场景云电脑使用了 LVM 并加入了数据盘用户在重装系统前需要先从 LVM 卸下来。这句话听起来有点绕但它描述的是云环境下的典型坑。云电脑或云服务器通常把系统盘和数据盘分开。重装系统时云平台一般只格式化系统盘数据盘里的内容原样保留。问题在于如果数据盘之前已经加入了 LVM 卷组那数据盘头部记录着 LVM 元数据。新系统启动后LVM 服务会自动扫描所有磁盘发现这个旧卷组一旦自动激活就可能把数据盘挂到奇怪的位置甚至和新系统的卷组同名冲突造成数据不可见或挂载混乱。所以“从 LVM 卸”不是让你拔线而是把数据盘上的卷组先停用并导出卸载文件系统、停用卷组、导出卷组标记让数据盘变成一个“有 PV 信息但未激活”的状态。重装系统后再导入卷组并激活数据就稳稳当当地回来了。具体命令我在第 5 节完整演示。4. 手把手搭建 LVM创建、扩容、缩容、删除全流程4.1 实验环境规划为了不让你对着术语空想我模拟一个最典型的场景机器上有两块数据盘 /dev/vdb 和 /dev/vdc各 500G现在要把它们做成一个卷组 vg_data从中划出一个 200G 的逻辑卷 lv_data挂载到 /data 目录。以后容量不够直接在线扩增。开始之前先用 lsblk 确认两块盘都没有被系统使用。如果之前有过分区建议先清掉分区表再操作避免旧分区信息干扰lsblk parted -s /dev/vdb mklabel gpt parted -s /dev/vdc mklabel gpt在这一步有个细节我建议你先把整块盘建一个 GPT 分区再在这个分区上做 PV而不是直接对整块裸盘做 pvcreate。原因有两个一是大多数运维工具和管理界面认分区比认裸盘直观二是后续如果要做 RAID、替换磁盘、云平台快照分区方式更不容易出歧义。4.2 创建 PV 与 VG分区完成后把分区标记为 LVM 类型然后初始化物理卷parted -s /dev/vdb mkpart primary 1MiB 100% parted -s /dev/vdb set 1 lvm on parted -s /dev/vdc mkpart primary 1MiB 100% parted -s /dev/vdc set 1 lvm on pvcreate /dev/vdb1 /dev/vdc1 pvspvs 的输出会列出每个 PV 的名称、大小、所属 VG。此时 VG 列应该是空的。接着创建卷组vgcreate vg_data /dev/vdb1 /dev/vdc1 vgs vgdisplay -vvgs 会显示 vg_data 总容量约 1000G两块 500G 盘合并剩余空间也是 1000G。vgdisplay -v 可以看到更详细的内容包括 PE 大小、PV 数量、每个 PV 的空闲 PE 数。新建卷组的 PE 大小默认是 4MB这也是 LVM 操作里出现“容量总是 4MB 倍数”的原因。4.3 创建 LV、格式化并挂载从 vg_data 里划出 200G 的逻辑卷lvcreate -L 200G -n lv_data vg_data lvs这里 -L 指定大小-n 指定名字。创建完成后在 /dev/mapper/vg_data-lv_data 和 /dev/vg_data/lv_data 两个路径下都能访问到这个逻辑卷两者实际指向同一个设备。接下来格式化并挂载mkfs.xfs /dev/vg_data/lv_data mkdir /data mount /dev/vg_data/lv_data /data df -h /datadf -h 应该能看到 /data 是 200G 的 xfs 文件系统。此时可以用 blkid 拿到 UUID按第 2.4 节的方法写入 /etc/fstab确保重启后仍能自动挂载。4.4 在线扩容最常用的 LVM 操作几个月后 /data 不够用了df -h 显示使用率 92%。由于卷组还剩 800G直接扩容逻辑卷就行lvextend -L 50G /dev/vg_data/lv_data这条命令把 lv_data 扩大 50G。但注意逻辑卷扩大了不代表文件系统也扩大了。xfs 文件系统需要额外执行xfs_growfs /dataext4 文件系统则执行resize2fs /dev/vg_data/lv_data我见过无数人只执行 lvextend结果 df -h 容量没变就以为扩容失败。其实 LVM 层已经成功了只是文件系统还没感知到空间变化。xfs_growfs 和 resize2fs 就是把文件系统扩展到逻辑卷当前大小。如果卷组本身也不够用就需要加一块新盘进来pvcreate /dev/vdd1 vgextend vg_data /dev/vdd1 lvextend -L 200G /dev/vg_data/lv_data xfs_growfs /data这是 LVM 跨磁盘聚合的典型场景加盘、扩 VG、扩 LV、扩文件系统整个过程不需要卸载业务无感。4.5 缩容只在 ext4 上操作且必须谨慎缩容是 LVM 里最危险的操作原则是xfs 文件系统不能在线缩小如果必须在 xfs 上缩容量只能备份数据、重新创建 LV 和文件系统、再恢复数据。ext4 支持缩容但也必须按严格顺序执行。ext4 缩容示例把 LV 从 200G 缩到 150Gumount /data e2fsck -f /dev/vg_data/lv_data resize2fs /dev/vg_data/lv_data 150G lvreduce -L 150G /dev/vg_data/lv_data mount /data先卸载再强制检查文件系统然后先缩文件系统再缩逻辑卷。顺序反了会直接损坏数据。缩容前一定要有备份而且不要在生产业务上轻易做这个操作。4.6 删除 LVM清理要按顺序来当你不再需要这套逻辑卷时按“卸载 → 停 LV → 删 LV → 删 VG → 删 PV”的顺序清理umount /data lvchange -an /dev/vg_data/lv_data lvremove /dev/vg_data/lv_data vgremove vg_data pvremove /dev/vdb1 /dev/vdc1每个步骤都会询问确认遇到“LV 正在使用”就检查是否还有进程占用挂载点不要强行删除。5. 云电脑与服务器场景LVM 数据盘的剥离、重装与重挂载5.1 重装系统前安全剥离数据盘的操作清单回到开头那句“如果云电脑使用了 LVM 并加入了数据盘重装前需要先从 LVM 卸下来”。很多人在云平台上重装系统以为只要不勾选“格式化数据盘”数据就绝对安全。但如果你把数据盘加入了 LVM情况会更复杂。正确的剥离操作清单如下# 1. 卸载所有挂载在数据盘逻辑卷上的目录 umount /data # 2. 停用卷组让 LVM 不再激活该卷组 vgchange -an vg_data # 3. 导出卷组告知其他系统这是一个可以安全移动的卷组 vgexport vg_data # 4. 关机或在云平台控制台分离数据盘vgexport 这一步非常关键。它会在卷组元数据里打上“已导出”的标记防止其他系统在启动时自动激活。做完这三步数据盘就处于“卷组已导出、PV 元数据保留、数据完整”的安全状态。这时再去云平台执行重装系统或分离数据盘风险就小多了。5.2 重装系统后如何把数据盘接回去新系统装好后把数据盘挂载回去执行pvscan vgscan vgimport vg_data vgchange -ay vg_datapvscan 会扫描所有磁盘上的 PV 信息vgscan 会发现已导出的卷组。vgimport 把导出的卷组重新纳入系统管理vgchange -ay 激活卷组。之后进行 lvs 确认逻辑卷存在再创建挂载点并挂载mkdir /data mount /dev/vg_data/lv_data /data如果你重装前没有做 vgexport新系统在 vgscan 时通常也能发现卷组并自动导入。但保险起见我仍然建议养成先卸载再 vgchange -an 再 vgexport 的习惯尤其是卷组名和系统默认卷组名相同时这个流程能避免自动激活带来的意外冲突。5.3 忘了解除 LVM 直接重装新系统里数据盘不显示怎么办我见过不少用户直接重装系统然后在新系统里 fdisk -l 能看到数据盘但 df -h 却没有对应的卷。原因就是 LVM 卷组处于未导入或冲突状态。这时不要慌张也绝对不要对数据盘重新分区、格式化。先看 pvs 是否能发现物理卷pvs -o pv_uuid vgscan -v如果 pvs 里能看到 PV说明数据盘的 LVM 元数据还在看不到就可能已经被覆盖那就只能靠备份或数据恢复工具处理。如果看到卷组但无法激活注意报错信息里的“duplicate”字样那通常意味着同一个 PV UUID 出现了重复或卷组名与现有卷组冲突用 vgrename 可以解决。处理完成后再走 vgchange -ay 和 mount。重要提示如果 pvs 和 vgscan 都正常但卷组被自动显示为 exported 状态就执行 vgimport 再激活如果显示 inactive直接 vgchange -ay。这一套流程处理下来数据盘基本都能恢复。5.4 云平台上设备名漂移问题云环境里重装后最常见的乱象是设备名变了原来数据盘是 /dev/vdb重装后变成 /dev/vdc甚至新系统的系统盘也占用了一个设备名。如果你 fstab 里写的是 /dev/vdb1 这种设备路径开机必挂载失败。解决方案就是我反复强调的fstab 全部用 UUID不要用设备路径。LVM 内部更是如此——物理卷靠 PV UUID 识别卷组靠 VG UUID 识别逻辑卷路径里也不依赖设备名。所以只要数据盘上的 PV 元数据没有被破坏无论设备名怎么漂LVM 都能靠 UUID 还原关系。这也是使用 LVM 在云环境里的一大优势。6. 常见问题排查与 LVM 运维速查6.1 扩容后 df -h 没变化这是 LVM 领域的第一高频问题。执行了 lvextendlvs 也显示逻辑卷变大了但 df -h 仍然是旧大小。排查思路很简单先确认文件系统类型然后执行对应的扩容命令。xfs_growfs /data # xfs 文件系统 resize2fs /dev/vg_data/lv_data # ext4 文件系统xfs_growfs 可以直接传挂载点也可以传设备路径resize2fs 则必须传设备路径。这两个命令都是幂等的执行后再 df -h 验证。注意一个细节某些老的 ext4 工具版本需要先 e2fsck再 resize2fs如果直接 resize 报错按提示先检查文件系统。6.2 开机进入 emergency mode如果系统开机后卡在“Welcome to emergency mode”这大概率是 /etc/fstab 里有挂载项失败。常见原因包括设备路径写错、UUID 写错、LVM 卷组未激活导致 /dev/mapper 路径不存在。处理方法输入 root 密码进入救援 shell先执行 mount -o remount,rw / 重新获得读写权限然后查看 /etc/fstab把有问题的行注释掉或修正重启验证。我的习惯是每次改完 fstab 都执行 mount -a 验证无误再重启同时给非关键数据挂载项加上 nofail 选项避免因一块盘临时缺失导致整个系统无法启动。6.3 卷组激活失败device not found执行 vgchange -ay 时提示找不到设备通常是某个 PV 对应的物理磁盘没有上线或者磁盘顺序变了导致 LVM 没扫到。排查顺序先 pvscan 看现在的 PV 是否都在再看系统里磁盘设备是否正常识别必要时用 vgchange -ay --partial 或 vgreduce --removemissing 处理缺失 PV。但要特别克制vgreduce --removemissing 会把缺失 PV 上的数据标记为不可用如果那块盘只是临时没插好数据还能救不要急着执行移除。处理办法是把盘重新接上、让系统识别后再激活卷组。6.4 LVM 元数据损坏恢复LVM 的元数据有自动备份机制备份存储在 /etc/lvm/backup/ 和 /etc/lvm/archive/ 目录。如果卷组元数据坏了可以用 vgcfgrestore 恢复vgcfgrestore -f /etc/lvm/backup/vg_data vg_data恢复前先确认备份时间点与当前状态差异恢复后立即 pvscan、vgchange -ay 激活验证。需要提醒的是如果是在故障后又对磁盘做了大量写操作备份文件的可用性会下降所以生产环境遇到元数据异常第一步永远是先停止对相关磁盘的写操作。6.5 常用命令速查表命令作用使用场景lsblk查看磁盘设备树任何磁盘操作前blkid查看 UUID 与文件系统类型写 fstab 前df -h查看文件系统使用率容量排查pvcreate/pvs/pvdisplay创建和查看物理卷初始化磁盘vgcreate/vgs/vgextend/vgreduce创建和调整卷组管理存储池lvcreate/lvs/lvextend/lvreduce创建和调整逻辑卷管理逻辑空间vgchange -an/-ay停用/激活卷组重装剥离、故障恢复vgexport/vgimport导出/导入卷组跨系统迁移数据盘xfs_growfs扩展 xfs 文件系统扩容后执行resize2fs扩展缩容 ext4 文件系统扩容/缩容后执行这张表基本上覆盖了日常 LVM 运维 90% 的命令需求。遇到问题先跑一遍大多数故障都有明确输出。6.6 两个实用习惯帮你减少一半 LVM 事故第一个习惯每次做 LVM 变更前先把当前 LVM 状态完整记录下来。执行 vgdisplay、lvdisplay、pvscan 后复制输出放到一个变更记录文件里备注日期和变更目的。真出了问题这份记录能帮你快速判断是操作前就存在问题还是操作过程中引入的。第二个习惯逻辑卷命名要带业务语义。别叫 lv1、lv2尽量用 lv_mysql、lv_log、lv_backup 这种一眼能看出用途的名字。卷组名也建议区分用途比如 data_vg、root_vg、backup_vg。等机器多了以后你会发现命名规整能让你在故障排查时省下大量思考时间。最后我自己的运维习惯聊到这儿Linux 磁盘管理和 LVM 的核心知识点基本都过了一遍。最后分享一个我实践多年养成的原则只要这台机器未来存在空间增长可能我一定在第一天就上 LVM哪怕当前磁盘还很充裕。因为磁盘告急是必然会发生的事等真的满了再想着怎么从传统分区里挤出空间要付出的代价往往是停机和数据迁移。每次对 LVM 做变更之前我会先确认备份目录情况变更完成后一定挂载验证并检查 df -h。这套流程帮我避开了不少险情。希望这篇文章能让你在 Linux 存储这条路上少走点弯路真正把这些命令变成自己的肌肉记忆。