1. 问题现场与核心逻辑1.1 根分区打满后系统会发生什么前阵子我碰上一台openEuler 20.03的服务器现象非常典型业务日志突然写不进去数据库连接数飙升SSH登录后敲命令都卡顿df -h一看根分区/的使用率妥妥停在100%。这种时候千万别慌也别急着想着“删点东西算了”——先搞清楚一件事根分区满了不是只影响你放文件整个系统都会跟着遭殃。Linux的根分区是所有系统路径的挂载点包括/var日志、缓存、/tmp临时文件、/usr应用程序甚至/run运行时目录。一旦/写满最常见的就是服务起不来、日志丢失、临时文件无法创建严重的直接导致某些进程崩溃或系统只读挂载。我见过最夸张的一次一台测试机根分区100%后连sudo命令都执行失败因为sudo要写/var/log/sudo.log盘满了根本写不进去。这种场景下很多人第一反应是“那我扩容呗”。理论上确实是这样但真正操作起来扩容报错的坑一个接一个——比如lvextend提示Insufficient free space、xfs_growfs提示设备忙或者明明磁盘加了容量系统却根本不认。这台openEuler 20.03就是这样扩容命令敲下去直接报错后面我会把整套排查思路和解决方案完整捋一遍适合所有用LVM管理磁盘的Linux系统参考不只是openEuler。1.2 openEuler 20.03的磁盘管理方式LVM原理要搞清楚扩容为什么报错得先明白openEuler 20.03默认的磁盘管理方式。openEuler 20.03是麒麟系实际上源自CentOS/RHEL技术路线的发行版安装时默认使用**LVMLogical Volume Manager**来管理磁盘这跟CentOS 8、RHEL 8的默认行为几乎一样。LVM的逻辑很好理解我用生活类比来说把物理磁盘比如一块500G的SATA盘想象成一块大土地LVM把它划分成若干个物理卷PVPhysical Volume相当于把土地切成几块“地块”。这些“地块”被合并进一个“土地储备中心”——也就是卷组VGVolume Group然后你从储备中心里划出一块地来挂载使用这就是逻辑卷LVLogical Volume。实际挂载到根分区的就是这个LV。好处是扩容时不需要动物理分区表只要卷组里有空闲空间就能实时分配给LV文件系统也能在线扩容。但问题也藏在这里很多人扩容时根本不看VG里还有没有空间直接对LV下手不报错才怪。所以当你执行扩容时报错优先要确认三件事物理磁盘本身还有没有空余空间——这决定你能不能扩PV。VG里有没有空闲空间——这决定你能不能直接扩LV。文件系统类型是什么——xfs和ext4扩容的命令完全不同。下面我用实际命令来拆解这整个过程顺便把报错现场一个一个还原。2. 排查思路先搞清楚扩容报错的真正原因2.1 第一步确认分区使用率与挂载点遇到根分区100%的问题最先做的不是扩容而是把现状摸清楚。我建议按这个顺序执行df -hT这能看到每个挂载点的文件系统类型、容量、使用率。输出长这样Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/openeuler-root xfs 200G 200G 20K 100% /注意第一列如果根分区是/dev/mapper/xxx-root这种路径那就确认走了LVM如果直接是/dev/sda2这种说明没有用LVM扩容路径完全不同。在我这台openEuler 20.03上根分区挂载的就是/dev/mapper/openeuler-root文件系统是xfs这很关键——xfs支持在线扩容但不支持缩容所以操作时不能缩回去这一点后面会细说。然后执行lsblk看整个磁盘拓扑lsblk输出里能看到物理磁盘、分区、PV、LV的层级关系。比如NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 500G 0 disk ├─sda1 8:1 0 1G 0 part /boot ├─sda2 8:2 0 199G 0 part │ └─openeuler-root 253:0 0 199G 0 lvm / └─sda3 8:3 0 300G 0 part这个时候你已经能看到物理磁盘其实还有300G没有被LVM使用sda3就是空闲空间。如果lsblk里物理盘已经完全分配完了那扩容思路就得换成“加新盘”或者“清理空间”而不是干扩。2.2 第二步查看LVM卷组剩余空间lsblk看完物理层再看LVM层。执行pvdisplay vgdisplay lvdisplayvgdisplay里有个关键字段Free PE / Size。比如--- Volume group --- VG Name openeuler Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable VG Size 199.00 GiB PE Size 4.00 MiB Total PE 50943 Alloc PE / Size 50943 / 199.00 GiB Free PE / Size 0 / 0看到Free PE / Size 0 / 0就明白了——卷组里已经一点空闲空间都没有了。这就是为什么执行lvextend -L 50G /dev/mapper/openeuler-root会报错常见的报错信息有Insufficient free space: 12800 extents needed, but only 0 available或者Cannot extend volume group openeuler with 1 physical volumes: not enough free space到了这一步问题根源已经清楚了LV想扩容但VG里没有空间可分配。没有空间你怎么扩都报错。所以真正的解法是——先给VG扩展物理卷PV再给LV扩容最后扩展文件系统。2.3 第三步区分物理盘容量与LVM分配这一步最容易混淆。很多人看到lsblk里sda总共有500G但LVM只用到了199G就以为自己可以直接扩。这里有个关键区别物理盘容量 ≠ LVM可见容量。因为LVM只把加入了PV的分区纳入管理磁盘上未分区的空间、未加入PV的分区对VG来说都是“不可见的”。所以你在虚拟机、云平台控制台把磁盘从500G扩到800G之后进系统执行df -h使用率还是100%因为新增的300G根本没有创建分区、没有加入PVLVM感知不到。很多人的扩容报错本质上是卡在这一步——只加了物理盘没让系统“认”这个新空间。正确操作是把磁盘新增的空间创建成新分区然后pvcreate把这个分区加为物理卷再vgextend扩展卷组之后才能lvextend去扩容逻辑卷。还有一种情况——lsblk里已经有一个未使用的分区比如sda3占了300G但你pvdisplay里看不到它。那就说明这个分区还没有被初始化为PV需要先用pvcreate /dev/sda3把它加进来。3. 实操三种扩容路径与报错应对3.1 路径一卷组有剩余空间时的在线扩容如果你检查了vgdisplay发现Free PE / Size不为0恭喜你这是最简单的情况。直接在线扩LV就行。先看逻辑卷路径和文件系统类型前面已经在df -hT确认过了然后执行扩容lvextend -L 50G /dev/mapper/openeuler-root这里-L 50G意味着在现有基础上增加50G如果写-L 250G则是把LV直接扩到250G注意不是增加是最终大小。个人建议用号写法免得你记错当前大小导致扩过头或者扩少了。命令成功会输出类似Size of logical volume openeuler/root changed from 199.00 GiB (50943 extents) to 249.00 GiB (63743 extents). Logical volume openeuler/root successfully resized.到这里很多新手就以为完事了实际上还差最关键的一步扩展文件系统。因为LV扩容后文件系统不知道底层变大了不扩展的话df -h还是显示原来的大小。xfs用xfs_growfs /ext4用resize2fs /dev/mapper/openeuler-root执行完df -h确认根分区应该已经变大了。注意xfs文件系统扩容是不支持缩容的所以扩容前务必确认你要扩的空间够用别想着“先扩了再缩回来”。ext4倒是可以缩容但那需要离线操作生产环境很不建议。3.2 路径二物理磁盘有剩余空间时扩展PV这是本次openEuler 20.03报错场景里最常见的路子——磁盘在云控制台或者虚拟机软件里已经加了容量但系统里根本看不到。处理步骤依次是第1步新空间创建分区查看当前磁盘分区表fdisk -l /dev/sda假设你原来只有sda1和sda2两个分区磁盘从500G扩到800G后剩余300G是未分区状态。执行fdisk /dev/sda依次输入n新建分区p主分区分区号选默认回车即可通常下一个可用的就是3First sector 默认直接回车Last sector 默认直接回车使用全部剩余空间t修改分区类型填8eLinux LVMw保存退出这一步如果报错Partition 3 already exists说明系统里其实已经有分区了但可能没被LVM认。那就跳过fdisk直接看第2步。第2步初始化物理卷pvcreate /dev/sda3正常输出Physical volume /dev/sda3 successfully created.如果提示Device /dev/sda3 not found需要先执行partprobe让内核重新读取分区表或者干脆重启生产环境不推荐重启的话用partprobe就能解决。第3步扩展卷组vgextend openeuler /dev/sda3注意这里openeuler是我的VG名字你在自己机器上执行时先vgdisplay看清楚VG Name再替换。输出正常是Volume group openeuler successfully extended这时再执行vgdisplay就能看到Free PE / Size不再是0了。这个说法有点绕直接用vgdisplay看更直观。第4步扩展LV与文件系统lvextend -L 300G /dev/mapper/openeuler-root xfs_growfs /搞定。df -h确认下根分区是否已经更新。3.3 路径三没有额外磁盘空间时的应急处理如果机器本身没有额外空间了磁盘就那么大也没有云控制台加盘的条件那扩容这条路暂时走不通。这时候先做应急把系统盘的使用率压下来保住业务再去申请资源扩盘。梳理一下我常用的清理方法日志压缩与清理journald日志是最容易吃满空间的东西之一尤其是/var/log/journal目录。执行journalctl --vacuum-size500M这会把历史日志裁到500M以内效果立竿见影。想永久限制journal日志大小改配置mkdir -p /etc/systemd/journald.conf.d cat /etc/systemd/journald.conf.d/size.conf EOF [Journal] SystemMaxUse500M EOF systemctl restart systemd-journald包管理器缓存清理openEuler 20.03的yum/dnf缓存通常也在/var/cache/dnf执行yum clean all能释放不少空间具体取决于你用yum装了多少东西。大文件排查如果清理完日志和缓存还是不够就得找一找哪些文件在“偷偷”吃空间du -x --max-depth1 / | sort -rh | head -20这一条命令从根开始逐层找最大的目录然后逐层深入直到定位到具体的大文件。常见的“吃空间大户”有后端服务的日志文件比如/var/log/nginx/access.log、Docker的overlay2目录/var/lib/docker、数据库的binlog/var/lib/mysql等。临时文件与core dumprm -rf /tmp/* rm -f /var/crash/*这些目录往往堆着一堆没用的临时文件和崩溃转储清理完系统会松快很多。这几种方式都是应急手段能把使用率先压到70-80%保证系统能正常写日志、跑服务。但治标不治本后续还是要申请新磁盘空间按前面路径二的流程做一次真正的扩容。4. 常见报错速查与避坑经验4.1 典型报错对照表这个场景下我收集了比较常见的报错以及对应的解决办法整理成一张表方便直接对照排查。报错信息原因解决方案Insufficient free space: NNNN extents needed, but only 0 availableVG里没有空闲空间新磁盘分区 - pvcreate - vgextend然后再lvextendCannot extend volume group ... no free space同上VG可分配的物理空间不足同上重点检查物理盘有没有新加容量xfs_growfs: / is not a mount point命令参数写错直接执行xfs_growfs /不需要指定设备路径resize2fs: Bad magic number in super-block在xfs文件系统上用了resize2fs改为xfs_growfs /xfs用xfs_growfsext4用resize2fsPartition 3 already exists磁盘上已有分区但未加入PV跳过fdisk直接pvcreate对应分区Physical volume /dev/sda3 not found内核还未识别新分区执行partprobe重新读取分区表或重启multipathd: sda: failed to get ...多路径环境磁盘盘符未刷新云环境下确认块设备状态重新扫描scsi总线No space left on device但df -h显示不到100%inode耗尽用df -i检查inode使用率确认是否有大量小文件占满inode最后一条值得单独强调。inode耗尽是个“隐形杀手”它不会显示成磁盘满了但症状一模一样——文件写不进去、服务报错。我遇到过/var/spool下大量邮件小文件把inode吃满的情况。排查命令是df -i如果IUse%接近100%解决办法是删除无用的小文件把文件数量压下来。4.2 我的几条实操心得做了这么多年的系统运维扩容这件事踩过的坑比吃的饭还多。分享几条自己的心得希望你能少走弯路。第一条扩容前先用df -i看一眼inode。别光盯着存储空间看。如果inode爆了就算你扩了磁盘写入照样失败。用df -i看一下每块分区的inode使用率特别是/var和/home这种可能堆大量小文件的分区。第二条不要在磁盘使用率100%的时候做lvextend。听起来有点反直觉——我扩容不就是为了解决100%吗我的意思是如果你还没获得新磁盘空间只是拿“清理空间”当挡箭牌那你更应该先扩充物理存储再决定是清理还是扩容。如果在根分区已经100%的状态下执行某些进程会持续写盘的扩容操作有中断风险。稳妥的操作是先清理出一部分空间让系统喘口气再扩容。第三条xfs_growfs不需要指定设备路径直接对挂载点操作就行。很多新手习惯看教程里的完整写法比如xfs_growfs /dev/mapper/openeuler-root这个写法其实也能用但在openEuler 20.03上直接xfs_growfs /更稳。原因是xfs_growfs命令针对的是挂载点不是设备文件传挂载点才是最标准的方式。第四条云环境下扩容后别忘了扫描磁盘。如果你用的是云服务器在控制台加完磁盘容量后系统内不一定能自动识别。这种情况执行echo 1 /sys/class/scsi_disk/0:0:0:0/device/rescan或者重启。我最初就是忘了这一步导致磁盘容量加了好几次都没生效白白折腾了半天。第五条生产环境扩容前先备份。虽然LVM在线扩容是成熟技术但谁也不能保证万无一失。有备份的话即使扩出问题也能回滚这个钱和功夫省不了。4.3 一次真实的扩容复盘最后把这次openEuler 20.03的排查过程完整复盘一遍更直观地展示实际处理的节奏。现象df -h显示根分区/使用率100%系统卡顿日志写入失败。 排查lsblk看到sda磁盘总大小500Gsda2分区199G被LVM使用sda3分区300G未被使用。 关键点pvdisplay里没有sda3这个PVvgdisplay里Free PE / Size为0。 报错执行lvextend -L 300G /dev/mapper/openeuler-root提示Insufficient free space。 定位300G的空间确实存在但没有初始化为物理卷LVM完全看不到它。 解决pvcreate /dev/sda3——把sda3加入LVM物理卷。vgextend openeuler /dev/sda3——把新的PV扩展到VG中。lvextend -L 300G /dev/mapper/openeuler-root——扩展LV。xfs_growfs /——在线扩展xfs文件系统。 验证df -hT确认根分区从199G扩到了499G使用率降到50%左右。整个过程其实不超过10分钟但之前卡在报错上花了大半天。所以我想强调的是扩容报错时第一反应应该是“VG里有没有空间”而不是“为什么lvextend不给过”。搞清楚了LVM的工作机制90%的扩容问题都不是问题。根据我个人在openEuler 20.03上的使用体验它的LVM链路和CentOS/RHEL非常接近所以这套操作思路放到同类系统上基本通用。如果你用的不是LVM而是裸分区比如直接挂载的/dev/sda2那扩容路径完全不同需要借助分区工具或直接重建文件系统但那就是另一篇文章的内容了。