1. 磁盘告警后的第一步排查先别急着扩容凌晨两点收到磁盘空间告警邮件这是运维人最不想看到的消息之一。如果你对Linux磁盘扩容的流程还不算熟悉面对磁盘已满四个字往往会手忙脚乱——不敢重启、不敢删文件、更不敢随便动分区。其实Linux磁盘扩容是个非常有章法可循的操作前提是你得先搞清楚三件事文件系统是哪种类型、磁盘用的什么分区方案、当前是LVM还是非LVM。这三件事决定了你后续该走哪条扩容路径也决定了哪些命令能用、哪些命令坚决不能用。我的习惯是任何扩容操作开始前先用下面这一组命令把家底盘清楚# 1. 查看文件系统的使用率与挂载点 df -hT # 2. 查看块设备、分区与挂载点之间的关系 lsblk # 3. 查看分区表类型和具体分区信息 fdisk -l /dev/vda # 或者对于GPT磁盘用 parted -l /dev/vda # 4. 查看分区的UUID和文件系统类型 blkid这四条命令各司其职。df -hT能直接告诉你哪个挂载点快满了、文件系统是什么格式比如常见的是xfs还是ext4lsblk能看出磁盘物理上有没有未分配的空间以及当前各个分区是怎么挂载的它输出的树状结构比/proc/partitions直观得多fdisk -l或parted -l用来确认分区表是MBR还是GPT这直接关系到你是否能在线扩容blkid则帮你确认分区UUID和文件系统类型避免你扩容错了设备。我曾经接过一个排障单同事说磁盘满了但df -h显示/dev/sda1使用率 99%他准备扩/dev/sda1。结果我用lsblk一看/dev/sda总共 100G/dev/sda1只分了 20G剩下的 80G 其实还是空闲空间——根分区之所以满仅仅是因为当初装机时给根分区分配得不够大压根不需要加新磁盘直接在原磁盘上扩分区就行。所以花两分钟做排查比盲目操作节省的时间要多得多。1.1 通过 df 输出判断文件系统格式df -hT输出中每一行都包含文件系统类型这个信息至关重要。我截一个典型输出作为参考文件系统 类型 容量 已用 可用 已用% 挂载点 /dev/mapper/vg0-root xfs 50G 47G 3.6G 93% / /dev/vda1 ext4 976M 190M 739M 21% /boot tmpfs tmpfs 7.8G 0 7.8G 0% /dev/shm /dev/sdb1 ext4 2.0T 1.3T 721G 64% /data从这份输出里你能读出不少信息根文件系统是 xfs挂在 LVM 逻辑卷/dev/mapper/vg0-root上/boot是独立的 ext4 分区/data是单独数据盘。接下来我要扩容的目标通常是类似根分区这种 LVM 逻辑卷 或/data这种 独立物理分区。1.2 关键判断LVM 还是非 LVM扩容路径的第一大分水岭就是 LVM。我把两种方案的核心差异整理成下面这个表格方便你对照自己的环境维度LVM 方案非 LVM 方案底层结构PV物理卷→ VG卷组→ LV逻辑卷→ 文件系统磁盘 → 分区 → 文件系统扩容方式往 VG 里加 PV再扩展 LV扩展分区大小或新建分区在线扩容几乎不需要停机可在线完成大多数情况可在线GPT 分区表更稳妥是否支持缩小支持但生产环境强烈不建议非常困难通常需要重新分区典型使用场景系统盘、数据库数据盘云主机系统盘、简单数据盘为什么 LVM 被生产环境偏爱因为它把物理磁盘容量抽象成了逻辑空间池你可以随时往卷组里塞一块新磁盘然后像调整水池水位一样给任意逻辑卷分配空间。而传统分区扩容受限于相邻空闲空间和分区表格式一旦分区排满了想扩大某个分区就得冒着风险动前后分区非常痛苦。2. LVM 卷组扩容从物理磁盘到逻辑卷的完整链路如果你的系统盘或数据盘是 LVM 管理的那么扩容路径最为顺畅也是我最推荐生产环境采用的方案。整套操作只需要沿着 LVM 的逻辑链条走一遍新磁盘 → PV → VG → LV → 文件系统。下面我用一个实际场景演示完整过程。假设当前环境如下卷组叫vg0里面的根逻辑卷叫root挂载在/上现在/使用率 95% 告警。服务器上刚插入了一块新的 200G 磁盘/dev/sdb在虚拟化或云环境里相当于你新加了一块云盘。2.1 第一步把新物理磁盘初始化为 PV先确认系统识别到了新磁盘lsblk # 输出应能看到类似 /dev/sdb 的磁盘且没有分区 # 将整个磁盘初始化为物理卷 pvcreate /dev/sdb这里要说明一点你既可以把整块磁盘直接做 PV也可以先在磁盘上建一个分区比如/dev/sdb1再把分区做 PV。有些强迫症运维喜欢建分区理由是 看到分区心里踏实且便于将来区分用途我个人的习惯是如果整块盘专属于一个卷组直接pvcreate /dev/sdb就够了。如果一块盘将来可能拆成多个用途才需要先分区。两种方式对 LVM 来说没有本质区别LVM 会自己处理好物理卷边界。2.2 第二步把 PV 加进现有 VG 卷组查看现有卷组名称和剩余空间vgs # VG #PV #LV #SN 属性 VSize VFree # vg0 1 2 0 wz--n- 99.00g 1.00g看到没有vg0的 VFree 只剩不到 1G这就是根卷扩容空间不足的直接原因。把新 PV 加进去vgextend vg0 /dev/sdb执行完再vgs看一眼VSize 应该变成约 299GVFree 约 201G。这一步非常快不会影响正在运行的业务也是 LVM 方案最舒服的地方。2.3 第三步扩展逻辑卷 LV现在把根逻辑卷扩到 250G。两种写法# 写法一指定目标大小 lvextend -L 250G /dev/vg0/root # 写法二把卷组所有剩余空间全部给该 LV lvextend -l 100%FREE /dev/vg0/root # 写法三追加指定容量 lvextend -L 50G /dev/vg0/root这里我需要提醒一个参数细节-L 50G和-L 50G是完全不同的意思。前者是在当前大小上追加 50G后者是直接把 LV 设置成 50G。如果当前 LV 是 30G你写-L 50G会被系统按设置到 50G来处理千万别搞混。我见过不止一次因为少写了号把逻辑卷缩回去的案例虽然 LVM 会警告但你要是-L 10G这么写那可是有数据损坏风险的。2.4 第四步扩展文件系统LV 变大了但文件系统还是原来的大小这一步才是真正让df -hT显示容量变化的操作。根据文件系统类型二选一# ext4 文件系统 resize2fs /dev/vg0/root # xfs 文件系统RHEL/CentOS 7 默认 xfs_growfs /注意resize2fs后面跟设备路径或挂载点都行它自动检测容量并扩展xfs_growfs通常直接跟挂载点也可以跟设备路径。执行完df -hT验证df -hT /如果一切正常挂载点容量已经变为 250G。整套流程从pvcreate到resize2fs全程在线操作不需要卸载文件系统也不需要重启服务器这就是 LVM 在生产环境中无法被替代的原因。3. 非 LVM 磁盘分区在线扩容growpart 与 resize2fs/xfs_growfs 的组合拳没有 LVM 的系统盘扩容是另一番景象。现在很多云主机的默认系统盘比如/dev/vda1挂载/它是非 LVM 的普通分区初始化时只分配了 40G但云厂商后台你把系统盘配额升到了 100G。这个时候你不需要重新分区也不建议重新分区正确做法是先扩展分区表再扩展文件系统。3.1 先扩展分区growpart 的用法growpart这个工具来自cloud-utils-growpart包Debian/Ubuntu 通常自带RHEL/CentOS 可以通过yum install cloud-utils-growpart安装。它的作用是让指定的分区占满整个磁盘的可用空间。# 语法growpart 磁盘 分区号 growpart /dev/vda 1注意分区号前面有空格不要写成/dev/vda1。执行成功后用lsblk看/dev/vda1的大小应该已经扩展到接近整个磁盘大小。如果你的磁盘是 GPT 分区表分区表末端的备份分区表会被 growpart 自动处理通常在线操作没问题。如果是老的 MBR 分区表且原始分区已经用满了 4 个主分区的配额扩展空间可能受限此时需要parted或gdisk之类的工具介入或者干脆换 LVM 方案最省心。3.2 再扩展文件系统resize2fs 与 xfs_growfs 的选择分区表扩展完文件系统还停留在旧大小继续执行在线扩展# 如果文件系统是 ext4 resize2fs /dev/vda1 # 如果文件系统是 xfs xfs_growfs /我把这个组合拳总结成三句话分区表扩展用的是 growpart文件系统扩展用的是 resize2fsext4或 xfs_growfsxfs。两个都要做漏掉任何一个df都不会变。实际操作中我见过不少人在云控制台扩展了磁盘容量然后兴冲冲跑到系统里df -h发现一点没变原因就是只做了云端扩容没有执行分区扩展和文件系统扩展这两步。这不是系统坏了只是链路没有打通。3.3 ext4 与 xfs 在扩容上的性格差异写到这里非常有必要把 ext4 和 xfs 的扩容差异讲透因为这是大家在日常操作中最容易踩坑的地方。对比项ext4xfs扩容方向支持在线扩大和缩小缩小需先卸载只支持在线扩大不支持缩小扩容命令resize2fs /dev/设备xfs_growfs 挂载点缩小文件系统可缩小但操作复杂且有风险完全不支持缩小需备份重建扩容后立即生效是是典型适用通用数据盘、启动分区RHEL/CentOS 默认文件系统所以这里有个非常重要的提醒如果你的根文件系统是 xfs千万别想着磁盘空间分配多了想缩回来——xfs 根本没有缩小的官方在线方案。网上有些教程让你通过xfs_admin改某些参数那些操作风险极大稍有不慎文件系统直接损坏。生产环境里xfs 分区一旦创建我只能建议你做好容量规划或者趁早把数据迁移到 ext4 或 LVM 方案上。xfs 的思路是忠于设计只增不减这个特性你越早接受后面越少走弯路。4. 云主机与虚拟化环境扩容从控制台到系统内的完整链路现在的 Linux 服务器不管是物理机、虚拟机还是云主机扩容磁盘时都不能只盯着系统内部命令外部层面虚拟化平台或云控制台往往需要先行一步。这一节我把三种常见环境的操作链路分别梳理一遍。4.1 云主机以阿里云/腾讯云为例云主机扩容磁盘通常两条路径系统盘扩容和数据盘扩容。以系统盘扩容为例在云控制台找到该云主机实例选择云盘点击扩容把系统盘容量从 40G 改成 100G确认支付。回到 Linux 系统内先确认设备已识别到新容量lsblk # 正常情况下 /dev/vda 应该已经显示为 100G如果lsblk显示磁盘还是旧大小部分云平台需要重启实例才能识别大部分情况下lsblk会直接刷新。接着执行growpart /dev/vda 1 resize2fs /dev/vda1 # 或者 xfs_growfs /两三分钟搞定。数据盘扩容的思路完全一致只是挂载点不同比如/dev/vdb1挂/data那就growpart /dev/vdb 1、resize2fs /dev/vdb1。有一件事必须提醒线上操作前一定先去云控制台确认是否支持在线扩容。某些云平台要求你先创建快照或停止实例才能扩容如果你在系统里把分区表改了结果控制台扩不动那才叫真被动。我的习惯是先看云平台文档再动手这能避免不少麻烦。4.2 VMware/KVM 虚拟机宿主层扩展后再进系统虚拟化环境的扩容链路本质是宿主层给磁盘加空间 - 客户机系统内扩分区/文件系统。VMware vSphere 环境在主机上选中虚拟机编辑设置把硬盘从 50G 改成 100G。这里有一个关键参数——磁盘置备里如果选的是厚置备延迟置零扩容后客户机内直接能看到新容量如果选了精简置备也要在客户机内确认。客户机系统内执行echo 1 /sys/class/block/vda/device/rescan # 或者部分环境用 partprobe lsblk确认磁盘识别到 100G 后再走growpart /dev/vda 1和后续文件系统扩展。KVM/libvirt 环境取决于你管理虚拟磁盘的方式。如果是 qcow2 镜像可以用qemu-img resize直接扩大磁盘文件qemu-img resize /var/lib/libvirt/images/disk.qcow2 100G或者用virsh blockresize在线调整virsh blockresize testvm vda --size 100G之后同样进客户机系统执行分区分区表和文件系统扩展。注意虚拟化平台上磁盘大小调整后客户机如果一直看不到新容量先确认 SCSI 或 virtio 驱动是否正常再确认是否需要partprobe或重启。不要贸然操作分区表避免驱动识别不全导致误扩容到错误设备。4.3 物理机加新磁盘还是扩容整列物理服务器的磁盘扩容路径又不同。你能操作的通常有两种一是往 RAID 卡里加新物理盘扩大 RAID 阵列容量二是直接插入新的独立磁盘走 LVM 或裸设备方案。如果是 LVM 方案插入的新盘比如/dev/sdcpvcreate /dev/sdc vgextend data_vg /dev/sdc lvextend -l 100%FREE /dev/data_vg/lv_data resize2fs /dev/data_vg/lv_data # ext4 # 或 xfs_growfs /data # xfs如果是独立新盘比如插入一块 4T 盘挂到/data1fdisk /dev/sdc # 或者 parted / gdisk mkfs.xfs /dev/sdc1 mkdir -p /data1 echo /dev/sdc1 /data1 xfs defaults 0 0 /etc/fstab mount -a至于 RAID 阵列在线扩容不同 RAID 卡命令差异很大如果是外置阵列通常有专门的存储管理软件扩容后操作系统能看到新空间再按磁盘分组方案执行系统内扩容操作即可。我不在这里展开因为具体命令取决于你的硬件厂商但整体链路依然是硬件层扩容量 - 系统层扩分区 - 文件系统层扩容量。5. 扩容实操中的常见坑与排错思路扩容看似几条命令实际踩坑点非常多。我不打算只列命令而是把当年自己踩过和帮别人排查过的坑都拎出来讲讲这些细节比命令本身值钱得多。5.1 扩容后 df 没变化最容易被骂白操作的坑现象分区、文件系统都执行了扩容命令df -hT还是老样子。排查链路是先确认磁盘物理容量有没有真正变大lsblk。如果磁盘本身没变那问题在外部环境云平台、虚拟化层系统内无论如何都没用。再确认分区表有没有扩大fdisk -l /dev/vda对比第一行显示的分区大小。如果分区没扩说明growpart没生效多半是磁盘本身的还有未分配空间或者分区表格式不支持在线扩需要重扫。再确认文件系统扩展命令有没有执行df -hT和lsblk的差异就在这一层。ext4 用resize2fsxfs 用xfs_growfs两者不可混用。实际工作中我还遇到过一种情况resize2fs执行时报 The filesystem is already N blocks long. Nothing to do!这说明文件系统已经扩展过了只是你被缓存骗了。用df -hT看的时候内核是刷新了的通常不会骗人但如果有 NFS 或 container 等场景可能要检查 mount 参数中的size是否被固定。5.2 xfs 扩容后用错命令导致文件系统异常xfs 的文件系统扩展命令xfs_growfs可以直接接挂载点也可以接设备路径还可以指定-d参数xfs_growfs -d /这个命令平时很少出问题真正的坑在于你用的是 ext4 却执行xfs_growfs或者 xfs 却执行resize2fs系统都会直接报错但如果resize2fs在旧的确认逻辑之下对 xfs 执行不排除会造成数据结构检查异常。我的铁律是动手前一定用df -T或blkid再确认一次文件系统类型这个确认成本几乎为零但能避免文件系统损坏的风险。5.3 分区表 MBR 与 GPT 对扩容的影响老系统中的 MBR 分区表和现代系统的 GPT 分区表对扩容的体验差异很大。MBR 最多支持 4 个主分区2T 以上磁盘必须用 GPT而且 MBR 下如果分区间没有连续的未分配空间扩展分区大小就很麻烦。如果你的磁盘超过 2T 又是 MBR多半是一些老机器装的系统或者初始化时选了 MBR 模板。遇到这种情况我的建议很简单新系统一律用 GPT 分区表。老系统如果磁盘已经分区且使用率告急切到 LVM 或者干脆迁移数据到新盘是比较稳妥的思路。MBR 转 GPT 有gdisk工具可以实现但操作后分区号、启动方式都可能受影响不适合在线上毫无准备地操作。5.4 swap 分区的扩容思路swap 空间不够也是磁盘扩容的常见需求。swap 分区或 swap 文件的扩容逻辑和普通数据分区分开看一块新磁盘做 swapmkswap /dev/sdc1 swapon /dev/sdc1 echo /dev/sdc1 swap swap defaults 0 0 /etc/fstab扩大已有的 swap 文件swapfile 方式swapoff /swapfile dd if/dev/zero of/swapfile bs1G count8 mkswap /swapfile swapon /swapfile关于 swap 文件扩容有一个坑要提醒/swapfile在扩展前一定要先swapoff否则在用dd覆盖原文件时文件已被占用轻则报错重则把 swap 区域写坏导致系统内存异常。5.5 LVM 扩容时 VG 有空间但 LV 扩不上去这种情况多见于卷组 VFree 空间碎片化或者 LV 边界不连续。最常见的原因其实是你vgextend加的 PV 有分区表但分区类型不是Linux LVM代码 8e。某些厂商初始化磁盘时会把分区类型设成普通 Linux 分区LVM 虽然能 pvcreate但lvextend时可能识别异常。解决办法是# 查看 PV 信息 pvscan # 确保分区类型为 8e parted /dev/sdb set 1 lvm on我用parted改过太多次分区类型了改完再pvcreate、vgextend问题基本都能解决。5.6 扩容期间要不要停业务这是每个新手最爱问的问题。我的回答取决于文件系统类型和磁盘状态xfs在线扩容非常可靠业务可以不中断直接执行xfs_growfs。ext4resize2fs支持在线扩展但为了保险如果扩展幅度特别大比如 500G 以上我建议在低峰期执行并对重要数据提前准备快照。整个 LVM 链路pvcreate/vgextend/lvextend全程在线不影响业务。但注意如果扩容的是系统盘且分区表增长涉及启动逻辑少数老版本 grub 环境需要重新生成引导配置或重启才能稳定引导。所以虽然操作可以不中断但最终验证环节比如确认重启后分区仍正确挂载、文件系统能正常自检是省不掉的。结尾说说扩容之后的那点事扩容命令跑完、df -hT显示容量终于上去了事情还没结束。我在实际维护中总结了几条扩容后的例行检查基本上每次都会做检查/etc/fstab里的挂载配置确保重启后能自动挂载尤其是新增数据盘时防止手滑写错 UUID 导致重启失败。对根分区和关键数据盘设置磁盘使用率监控如 80% 告警、90% 紧急告警不要让扩容变成只救火不防火。把扩容操作记录到变更单里写清楚扩容前容量、扩容命令、扩容后容量。别小看这个习惯几个月后排查问题时它比任何文档都有用。如果可以给扩容后的系统做一次验证性重启确认 grub、分区、文件系统都能正常起来。云主机和虚拟机的重启成本很低但能换来重启后才能放心的踏实感。最后再分享一个小技巧如果你经常需要处理磁盘扩容强烈建议在本地用虚拟机搭一套 LVM 测试环境把新加磁盘 - pvcreate - vgextend - lvextend - 文件系统扩容这套流程反复练熟。线上操作和实验环境最大的区别不在命令本身而在于你对异常输出是否敏感。多练几次看到 No space left 和 Nothing to do 之类的提示时你就不会再慌而是能顺着错误信息反推问题出在哪一层。磁盘扩容这件事说到底就是物理容量 - 分区 - 文件系统三级联动的链条把每一层的职责和命令搞明白你的 Linux 运维基本功就又扎实了一截。