排除日志把根分区塞满这种事情我在服务器上遇到过太多次。尤其是跑数据库、容器或者持续集成任务的主机磁盘空间总是以一种出乎意料的速度被消耗完。清理完日志之后磁盘依然紧张这时候最直接的办法就是扩容。Linux 磁盘扩容看起来是个老话题但真正动手的时候大部分问题都出在细节上分区表没重读、文件系统没扩充、LVM 流程里漏掉某一步任何一个环节断掉扩容就只能算做了一半。这篇文章把我实际用过、也踩过坑的几套扩容方案整理出来覆盖 LVM 卷组、传统裸分区、新增数据盘三种常见情况。每一段都会说明为什么这么做、哪些地方容易出问题、怎么排查。无论你是刚接触 Linux 运维还是已经有几年经验这套流程都能直接参考着来。1. 这个项目要解决什么问题1.1 常见的磁盘告警场景先聊聊什么时候你会意识到“该扩容了”。最典型的是df -h看到如下图一样的输出某个挂载点使用率达到 90% 甚至 100%紧接着服务开始报错数据库写入失败应用日志疯狂刷“No space left on device”。另一个是从监控面板上看到磁盘告警通常阈值设置在 80% 或 85%。具体场景也分几种日志类应用比如 Tomcat、Nginx、容器 stdout 日志日志文件一写就是几十 GB。数据库数据目录比如 MySQL 在 store 目录下累积了多个实例的 binlog或者 PostgreSQL 的 WAL 日志在长时间不清理时持续占用。持续集成构建机的缓存目录Java 构建工具、npm/yarn 缓存、Docker 镜像层叠加起来非常可观。文件上传类业务比如图片、视频、压缩包这类静态资源直接落在服务器本地。如果你确定是长期增长而不是一次性垃圾文件那“扩容”就是比“删删删”更值得投入的运维操作。不过扩容并不是简单的“加一块磁盘再挂上”就完事不同环境下有不同的处理路径。1.2 扩容前的三步自检每次动手之前我都会先做三件事避免走弯路。第一确认到底是哪一个磁盘分区满了。df -h显示的是分区或逻辑卷的使用率不代表整块物理磁盘已经用完。有些服务器给系统盘分了 50GB 数据分区但整块磁盘其实还有大量剩余空间。这时候你要把分区扩容到剩余空间里而不是急着加新盘。第二确认文件系统建立在什么之上。是 LVM 逻辑卷还是直接用了/dev/sda1这样的裸分区LVM 扩容路径是“磁盘 → 物理卷 → 卷组 → 逻辑卷 → 文件系统”裸分区路径是“磁盘 → 分区 → 文件系统”。两者操作命令完全不同提前判断能省下大量排查时间。第三确认虚拟化平台或云控制台里是否已经给虚拟磁盘扩容了。虚拟机场景下你必须先在 VMware、KVM、Hyper-V 或者云服务商控制台把虚拟磁盘容量调大然后在系统内部让内核重新识别新容量。很多教程默认“磁盘已经变大了”但实际操作时用户可能只改了这个外层参数内层完全没有反应于是卡在第一步。1.3 需要的工具与准备一套 Linux 磁盘扩容操作会用到这些基础命令lsblk查看块设备结构最直观。df -h查看文件系统使用率。pvs、vgs、lvsLVM 相关状态。fdisk、parted分区工具parted更适合 GPT 和大磁盘。growpart云服务器和虚拟化平台常用的小工具用于扩展分区。resize2fsext4 文件系统无损放大。xfs_growfsXFS 文件系统无损放大。个别发行版不会预装所有工具比如growpart通常属于 cloud-utils 包Debian/Ubuntu 用apt install cloud-guest-utilsCentOS/Rocky 用yum install cloud-utils-growpart。开工前先把命令检查一遍。2. 扩容前的准备工作与数据备份2.1 彻底摸清磁盘和分区布局先跑一遍这三组命令把现状搞清楚。lsblk -p lsblk -f df -hTlsblk -p会输出完整的设备路径能看到磁盘下面有哪些分区lsblk -f会额外显示每个分区上的文件系统类型和 UUID后面做自动挂载时用得上df -hT则把文件系统类型和挂载点一起列出来。举个例子某个虚拟机的输出可能是这样/dev/vda 50G vda1 ext4 /boot vda2 LVM / 实际挂载为 /dev/mapper/centos-root /dev/vdb 200G vdb1 xfs /data看到vda2的类型是 LVM你就知道根目录扩容要走 LVM 那套流程而不是直接 resize 分区。而/data是独立的裸分区vdb1如果这块磁盘剩余空间还够就可以直接扩分区和文件系统。再看一行命令确认分区表类型parted -l输出里能找到“Partition Table”这一行值是msdosMBR 分区表还是gpt这个信息直接决定你怎么处理分区边界。如果磁盘大于 2TBMBR 根本不支持必须用 GPT。2.2 确认 LVM 与非 LVM 分区的路线差异这一步直接决定后面所有操作。LVM 路线不管是物理磁盘还是虚拟磁盘加进来的空间先要被 PV物理卷接收然后才能分配给 VG卷组、LV逻辑卷最后文件系统增长。命令顺序是pvresize→lvextend→resize2fs/xfs_growfs。裸分区路线要么用growpart让分区吃到磁盘新增的空间要么用parted resizepart修改分区结束位置要么用fdisk删除分区再原起始位置重建然后同样走文件系统增长。这里有一个很常见的认知误区很多人以为只要把磁盘分区调大文件系统就会自动变大。实际上文件系统并不知道分区发生了变化必须单独执行文件系统扩容命令。这就像房子外边围了一道更大的院子但房门还是原来那么小你得自己把门拆了重新装。2.3 备份与风险预案扩容操作中最大的风险集中在两个地方分区调整和文件系统调整。尤其是想通过 fdisk 删除分区再重建的方法一旦起始扇区对不上数据会直接立消失。即使技巧再熟练我也建议操作前至少准备一份可靠备份。物理机或虚拟机建议先打快照。VMware 里可以做快照KVM 可以用snapshot-create-as云服务商控制台也都有创建快照入口。快照是在云平台侧完成回滚最稳的方式比在系统内部操作安全得多。注意一点打快照时如果磁盘上有数据库之类的高写入负载最好先停止写入或做一次一致性检查。对 MySQL 可以先锁表对 PostgreSQL 可以先pg_dump一次逻辑备份否则快照恢复后可能出现数据文件不一致。另外给每个操作步骤留一个“停手检查点”。比如在重新读取分区表之后立刻用lsblk确认分区大小不要急着往下一步走。如果发现容量没变化宁可停下来排查也不要盲目继续执行文件系统扩容命令。3. 实操一LVM 逻辑卷扩容完整流程LVM 扩容是生产环境最高频的需求。因为很多 Linux 发行版在安装系统时根分区默认就建在 LVM 里尤其是 CentOS、Rocky Linux、Ubuntu Server 的默认安装选项。3.1 让新增的磁盘空间被系统识别这里分成两种情况。情况一虚拟化平台里已经把虚拟磁盘调大了比如 VMware vSphere、Proxmox VE 或者云控制台的云盘扩容。系统里看到的是同一块盘但分区和磁盘容量都变化了。这种情况通常需要让内核重新扫描磁盘容量。如果磁盘是vda可以这样操作echo 1 /sys/class/block/vda/device/rescan如果磁盘是sda路径变成/sys/class/block/sda/device/rescan。执行后运行lsblk就能看到磁盘的总容量已经变化。有些老内核或特殊虚拟化环境不支持 rescan这时候最稳妥的办法是临时重启系统也能让内核重新识别。情况二控制台或“添加设备”里新增了一块磁盘比如从一块盘变成两块盘。这种情况下新盘通常是/dev/vdb、/dev/sdb但你可能看不到它被任何卷组引用需要手动将其变成 PV。3.2 扩展 PV 和 LV 的正确命令顺序先看当前 LVM 状态pvs vgs lvs假设当前物理卷是/dev/vda2卷组名是centos逻辑卷是centos/root。在虚拟磁盘容量已经被扩大之后执行pvresize /dev/vda2pvresize的作用是让物理卷感知磁盘分区的新容量。很多网上教程会漏掉这一步直接去执行lvextend结果提示“无法分配空间”或者lvextend看到的大小还是旧的实际原因就是 PV 大小没有刷新。验证一下pvs如果 PV 的 PSize 已经变成新容量说明pvresize生效了。接下来给根逻辑卷扩容。一般有两种写法# 指定增加 30G lvextend -L 30G /dev/centos/root # 直接把卷组剩余空间全部分配给根逻辑卷 lvextend -l 100%FREE /dev/centos/root生产环境我习惯用按需增加的方式即-L 30G这样以后还有缓冲空间能再扩。如果确认短期内不会再扩容直接用100%FREE也可以优点是简单缺点是卷组里少了灵活性。3.3 文件系统在线增长ext4 与 XFS 千万别搞混逻辑卷变大以后文件系统仍然保持原大小。你要根据文件系统类型执行对应的扩容命令。ext4 文件系统resize2fs /dev/centos/rootXFS 文件系统xfs_growfs /注意这里的差异resize2fs后面跟的是设备路径不关心挂载点xfs_growfs后面跟的是挂载点也可以是目录路径。如果你执行resize2fs目标其实是 XFS会直接报错“不支持的特性组合”反过来用xfs_growfs处理 ext4 也会看到错误。判断文件系统类型的方法很简单blkid /dev/centos/root或者直接看lsblk -f里的 FSTYPE 列。最后用df -h验证。如果看到根目录大小已经增大逻辑卷扩容就算全部完成了。整个过程都可以在线执行服务器不需要停机这条对于生产环境非常重要。3.4 顺手处理 swap 逻辑卷很多 LVM 安装会单独分出 swap 逻辑卷。如果内存压力大需要同步扩大 swap顺序类似lvresize -L 4G /dev/centos/swap mkswap /dev/centos/swap swapon /dev/centos/swap先扩大逻辑卷再用mkswap重新格式化 swap 区最后重新激活。如果/etc/fstab里写的是/dev/mapper/centos-swap完成swapon之后再检查swapon --show是否正常。另外要注意/dev/mapper/下的名称是逻辑卷映射出来的不代表它是物理设备。在 fstab 里写这些路径没有错但当你拿到一台新接手的服务器时最好用lvdisplay去确认 LV 的完整路径避免看到/dev/vg/lv和/dev/mapper/vg-lv两种形式后产生困惑。4. 实操二裸分区在线扩容不是所有系统都用了 LVM。很多独立数据盘、备份盘、容器目录就是以裸分区方式存在的。裸分区扩容没有 LVM 那么“优雅”但方法并不复杂关键是把分区边界理解清楚。4.1 使用 growpart 一步扩展分区在云服务器和多数虚拟化环境中最建议使用的裸分区扩容工具是growpart。它可以把指定磁盘上的指定分区扩展到磁盘最大可用空间而且不会改动分区的起始位置。假设/dev/vdb1挂在/data上磁盘/dev/vdb已经从 100G 扩大到了 200G操作是这样growpart /dev/vdb 1注意growpart的参数不是/dev/vdb1而是磁盘路径加分区号中间用空格隔开。它会把分区 1 的结束位置移动到磁盘的最大可用扇区。执行后再看lsblk此时能看到/dev/vdb1容量已经变成 200G。但文件系统仍然没变。接下来对号入座# ext4 resize2fs /dev/vdb1 # xfs xfs_growfs /data这套流程几乎不会碰坏数据因为growpart只扩展分区尾部。前提是分区前后没有奇怪的绑定关系像是多分区 MBR 结构以及某些 OEM 分区或恢复分区恰好挡在目标分区后面这种情况就要用别的方法。4.2 用 parted resizepart 处理 GPT 磁盘有些机器没有growpart系统又是 GPT 分区表可以用parted直接调整分区结束位置。先看一下当前分区布局parted /dev/vdb print输出会显示分区编号、起始位置和结束位置。假设分区 1 的结束位置在 100GB 处磁盘现在是 200GB执行parted /dev/vdb resizepart 1 100%100%表示把分区 1 扩展到磁盘末尾。如果是交互模式parted会询问是否确认因为在某些场景下需要内核重新读取分区表。执行完再次确认分区大小然后同样执行resize2fs或xfs_growfs。用parted resizepart的好处是 GPT 分区表下不需要删除重建分区理论上修改分区表更接近“原地改动”。不过任何分区表操作都带有一定风险执行前还是要验证磁盘本身没有硬件故障并且有备份。4.3 fdisk 重建分区法风险最高但有时候绕不开在某些老系统中分区落在一个中间位置前面有/boot后面有 swap还有空闲空间不连续试图“就地扩展”会很困难。这时候传统办法是用fdisk把分区删掉再以相同起始位置重新创建。操作逻辑是这样fdisk /dev/vdb在 fdisk 交互界面里输入p打印分区表记下目标分区的 Start 值比如 2048。然后d删除分区按分区号选择目标分区再n新建分区。新建分区时 fdisk 会提示 First sector一定要输入和原分区完全一样的起始扇区最后选择结束位置为新的磁盘末尾。保存退出后执行partprobe /dev/vdb让内核重新读取分区表。再执行resize2fs /dev/vdb1这个方法的危险点显而易见删除分区时分区表里指向该区域的记录就消失了如果新建分区时起始扇区多了一丁点或者少了一丁点文件系统元数据的位置就对不上数据就等于没了。所以我只建议在下面几种前提同时满足时才使用该分区不是系统启动分区最好只是数据分区。磁盘上没有正在运行的高写入业务。已经打了快照且验证快照能够恢复。操作者对 fdisk 交互命令非常熟练并且愿意接受一定风险。如果条件不满足我宁可选择新增一块磁盘并迁移数据过去也不要拿生产数据去赌。5. 实操三新增数据盘直接挂载目录有时候原地扩容的空间不够或者磁盘类型需要升级更合理的做法是新增一块独立数据盘挂载到指定目录然后把旧数据迁移过去。这种方式也适合“从 500G 机械盘升级到 2T SSD”这类场景。5.1 识别新磁盘、分区、格式化新增磁盘后比较常用的确认命令是lsblk你会看到一块全新的、没有任何分区的磁盘比如/dev/sdc。接下来选择分区表类型。单块数据盘容量在 2TB 以下MBR 和 GPT 都可以容量超过 2TB 必须用 GPT如果后续打算再扩容或者做 RAID建议直接上 GPT。parted /dev/sdc --script mklabel gpt parted /dev/sdc --script mkpart primary 0% 100%格式化时根据使用目的选择文件系统。常见选择是 ext4 和 XFS。大文件、高并发写入选 XFS通用场景 ext4 足够兼容性更好。mkfs.xfs /dev/sdc1 或者 mkfs.ext4 /dev/sdc1格式化之后查看块设备 UUIDblkid /dev/sdc1这个 UUID 后面写 fstab 时要用到比写/dev/sdc1更稳因为盘符在系统重启后可能因为内核识别顺序变化而改变。5.2 挂载到目录并写入 fstab 自动挂载新建挂载点目录然后手动挂载mkdir -p /data mount /dev/sdc1 /data检查是否成功df -h /data如果正常接下来把挂载关系写入/etc/fstab避免重启后消失。fstab 行是这样的UUIDxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data xfs defaults 0 2解释一下五个字段第一列是设备标识用 UUID第二列是挂载点第三列是文件系统类型第四列是挂载参数defaults是最常用的一组第五列是是否加入 dump一般写 0第六列是开机自检顺序0表示不检查根分区一般写1数据分区写2或0。写完后验证 fstab 是否正确这一点非常重要mount -a如果mount -a执行没有报错说明 fstab 内容可用。之后重启服务器也不会出现因挂载失败而进入维护模式的问题。5.3 旧数据迁移新磁盘挂载好之后把旧目录里的数据复制过去。这里我建议用rsync而不是cp因为 rsync 可以断点续传也适合大数据量长时间复制。举个例子要把/data_old迁移到新盘/datarsync -avP /data_old/ /data/注意源目录末尾要加斜杠含义是“复制目录内所有内容”不加斜杠会将目录本身嵌套进去。迁移完成后把原来的/data_old重新命名或者先不删等待业务验证通过后再清理。替换路径的方式可以直接改业务配置文件也可以用符号链接的方式减少改动mv /data_old /data_old.bak ln -s /data /data_old这种方式适合业务系统里硬编码了路径的场景先让软链接兜底后续再逐步改配置。6. 常见问题与排查实录磁盘扩容最容易出问题的地方不是“命令不熟”而是“命令顺序错了”或者“内核没有感知到容量变化”。下面这几个问题基本覆盖了我见过的大部分案例。6.1 系统不显示扩容后的磁盘容量在虚拟化平台或云控制台把磁盘调大后进系统执行lsblk看到的磁盘大小还是旧的。这种情况首先确认是否已经触发了内核重新扫描。对应磁盘路径执行echo 1 /sys/class/block/vda/device/rescan或echo 1 /sys/class/block/sda/device/rescan不同虚拟化驱动路径可能不一样。如果 rescan 不生效重启系统基本能解决。有些云服务商还要求在控制台执行“修复文件系统”或者额外点击“确认扩容”具体以平台文档为准。6.2 分区已经扩大但 df -h 仍然显示原大小这是典型的分区变了、文件系统没变。你需要区分lsblk和df -h的输出lsblk看到的是分区容量df -h看到的是文件系统容量。如果lsblk已经显示分区变大而df -h没变执行文件系统扩容命令即可。ext4 用resize2fsXFS 用xfs_growfs。我个人被问过很多次的一个情况是明明是 XFS却拿resize2fs命令去扩系统直接报错。先查看blkid里的 FSTYPE再决定用哪个命令。6.3 分区表重读失败partprobe或 fdisk 提示“设备正忙”或者重读失败通常是因为某个进程仍在使用这个分区。最简单的方法是重启系统让内核干净地重新加载分区表。如果不想重启可以尝试先卸载分区umount /data但根分区无法这样操作所以生产环境遇到底层分区调整时还是要做好重启的准备。6.4 LVM 扩容后卷组空间没有增加执行完pvresize再执行lvextend结果vgs看到 VFree 还是 0。先检查物理卷是否真的扩大了。执行pvdisplay看 PV Size 和 Allocatable 状态。如果 PV Size 没有变化说明pvresize当时没能识别到分区的新容量回到第 6.1 节的问题先把分区层面的容量解决好。有时还会遇到多个 PV 在同一卷组的情况例如/dev/vda2和/dev/vdb都在centos这个 VG 里扩容时选错了 PV导致lvextend找不到足够剩余空间。此时用pvs对照设备路径确认你扩容的磁盘正好对应哪个 PV。6.5 fdisk 重建分区后数据不见了如果在 fdisk 重建分区时起始扇区对不上文件系统里的超级块会找不到表现就是挂载失败。不要慌先确认之前是否记录过原分区的起始扇区。如果 fdisk 还保留在磁盘上的备份分区表可以通过严格回退找回。但完整恢复依赖当时是否打了快照所以再次强调上手 fdisk 重建分区前先确保能回滚。对于这种风险操作我的习惯是在动分区之前用sgdisk --backuptable.backup /dev/sdb导出 GPT 分区表备份。这样万一出现失误可以借助sgdisk --load-backup恢复整个分区表结构。6.6 扩容结束后文件系统报错扩容文件系统时突然断电或中断最有可能出现“文件系统需要修复”的问题。ext4 可以用e2fsck -f在卸载状态下检查XFS 可以用xfs_repair。不过这些命令一定要在文件系统已经卸载的情况下执行不要在挂载状态下运行否则风险极大。7. 一些值得留在笔记里的实操经验7.1 三种情况对应的最小命令清单我把常用命令整理成一张速查表方便你贴到自己的运维笔记里。场景核心命令序列备注LVM 逻辑卷扩容pvresize→lvextend→resize2fs或xfs_growfs逻辑卷路径用lvdisplay确认文件系统命令看 FSTYPE裸分区在线扩容growpart或parted resizepart→ 文件系统扩容命令先确认分区表类型GPT 用 parted 更合适新增数据盘挂载parted分区 →mkfs.ext4/xfs→mount→ 写 fstabfstab 总用 UUID写完后用mount -a验证新增磁盘加入 LVMparted分区 →pvcreate→vgextend→lvextend→ 文件系统扩容将新盘并入原卷组空间才可被逻辑卷使用7.2 平时容易忽略的两个习惯第一安装系统时如果数据量规划较大建议从一开始就把根分区放在 LVM 里并且单独分出/data或/var这类独立卷而不是把所有内容全部堆在根分区。LVM 在扩容灵活性上真的能省不少事。第二fstab 里尽量使用 UUID不要图省事写/dev/sda1。我遇到过一台机器因为内核识别磁盘顺序变化重启后/data挂到了别的盘上虽然没有数据损失但排查过程非常痛苦。磁盘扩容不是天天做但每隔几个月总要用一次。与其每次临时翻教程不如把常用的方案整理成一套流程先看结构再选路线最后验证。这个顺序顺手之后绝大部分扩容操作都能在十分钟内完成。