CentOS 7.9根分区100%满？从df与du差异到隐藏占用排查与清理

CentOS 7.9 根分区100%用满这种事我这些年遇到过太多次了。最典型的画面就是df -h一看/dev/mapper/centos-root已经用了100%但等你ssh上去准备清东西用du -sh /一层一层往下查又死活找不到对应的大文件。系统服务还在跑日志还在刷可是空间就是卡在满值一动不动。尤其是刚给CentOS 7.9做过OpenSSH升级、下载过离线安装包或者机器长时间不重启这种“隐藏占用”就更容易冒出来。这篇就把我实际排障的完整思路和解决办法记录下来遇到同样问题的朋友可以直接按顺序操作不用再像我第一次那样从头踩坑。先说清楚一个容易混淆的点df查的是文件系统层面的块占用du查的是文件层面的可见文件占用。这两者一旦对不上就说明一定有“看不见”的东西占着磁盘。这种隐藏占用最坑人因为你在正常目录里翻来翻去永远找不到答案。我后面写的所有排查步骤核心思路就一条把“文件系统占用”和“可见文件占用”之间的差值找出来然后针对性地处理。1. 先别慌确认一下“满”到底是哪一层1.1 df和du结果对不上问题出在哪很多人一看到根分区100%第一反应就是du -sh /然后一级一级往里面钻花费大量时间却一无所获。这不是你操作有问题而是df和du统计口径本身就不一样。df统计的是整个文件系统已分配的块只要块被占用了就算“已使用”。du则是顺着目录项去统计每个文件的逻辑大小。常规情况下一个文件占的块必然被某个目录项引用了两者差距不大。但隐藏占用场景就会破坏这个平衡最典型的有三类被进程删除但还没释放的文件、日志服务自己管理的滚动日志、以及文件系统保留块。这些文件要么在目录树里看不到要么根本不在普通目录里自然du不出来。所以我建议的排查顺序不是先找大文件而是先确认“差值”到底有多大。你先记录一下df -h /的已用空间再执行du -x -h --max-depth1 /其中-x参数是不要跨文件系统统计否则其他挂载点会把结果搅浑。这两组数字的差值就是隐藏占用的规模。1.2 五分钟内的系统体检快速圈定范围确定存在差值之后接下来要在五分钟内完成人工体检把可能的方向都摸一遍。我会依次执行下面这几条命令每一条都有它存在的意义df -h / df -i / du -x -h --max-depth1 / 2/dev/null | sort -hr | head -20 lsof L1 | head -30 journalctl --disk-usage第一条看容量第二条看inode第三条用-x参数避免跨文件系统统计干扰把根分区下各目录的大小排出来。第四条特别关键lsof L1用来列出所有“被删除但仍被进程打开”的文件这是隐藏占用的头号嫌疑。第五条看journald日志到底吃掉了多少空间。这几条命令跑完问题范围基本就圈定了。如果是journal日志占据十几G那就走第二章的日志清理方案如果lsof L1列出来一堆deleted文件那就走3.2的释放方案如果df -i显示100%但df -h还有空间那就是inode耗尽清理思路完全不同。别嫌这个步骤啰嗦方向错了后面所有动作都是白忙。2. 隐藏占用大户排查根分区100%到底谁占的2.1 journald日志最常见的隐形杀手在CentOS 7.9上journald日志是隐藏占用排行榜的常客。系统自带的systemd-journald默认情况下会一直保存日志只要磁盘允许它能把几个月的开机日志、服务报错、内核刷屏全部攒下来。更麻烦的是这些日志文件的目录在/var/log/journal下文件名是一长串十六进制字符你直接ls -lh看单个文件可能觉得每个都不大但整个目录加起来往往就是好几个G。我遇到过最夸张的一台机器根分区总共50Gjournal目录占了30G以上。它平时完全隐藏在后台不触发告警你可能根本注意不到。检查方法很简单journalctl --disk-usage这个命令会直接显示当前日志总占用。如果你看到的结果是GB级别那基本可以确定根分区爆满和它有直接关系。另外提醒一句有些精简过的CentOS 7.9镜像默认把日志放在/run/log/journal这是内存文件系统重启就没了所以不会造成持久化占用但如果你在/etc/systemd/journald.conf里设置了Storagepersistent日志就会持久化到/var/log/journal积累速度大大加快。2.2 被删除但仍占空间的文件比日志更隐蔽比日志更隐蔽的是已被rm删除但仍被进程占用的文件。这种场景经常出现在你升级软件之后比如用rpm -Uvh升级opensshd服务进程还在跑日志文件被logrotate切割后又被进程持续写入某个瞬间你删掉了一个正在被占用的日志或临时文件磁盘空间却没有真正释放。Linux的文件删除机制是这样的文件在磁盘上的数据块是否释放取决于还有没有进程持有它的文件描述符。只要进程不退出、不关闭这个描述符即便目录项已经没了数据块依然被标记为已分配。于是df看到的是“已使用”du在目录树里却找不到任何对应的文件。排查命令就是刚才提到的lsof L1。这个参数的含义是列出所有link count为0但仍打开着的文件。输出里会看到类似这样的行nginx 1234 root 2w REG 253,0 0 523456 /var/log/nginx/access.log (deleted)这里523456是文件inode号(deleted)表示已被删除。处理方案分两步先看是哪个进程、日志是否还需要如果确定是旧日志重启该服务即可释放如果不知道文件是什么不要盲目kill进程先继续排查。2.3 inode耗尽和“看不见”的临时文件还有一种隐藏占用的变体是inode耗尽。df -h显示根分区还剩几个G但df -i已经100%这时候你连创建临时文件都做不到很多服务会直接报No space left on device。这种情况通常是某个目录下堆积了海量的小文件常见于/var/spool/postfix/maildrop、/tmp、/var/tmp或者某些应用写错了路径一直在疯狂生成零字节文件。排查方法也比较直接for d in /tmp /var/tmp /var/spool /var/log; do echo $d: $(find $d -xdev -type f 2/dev/null | wc -l) done哪个目录的文件数量异常大就往哪个目录继续查。如果发现是maildrop这种邮件队列堆积清理后记得检查是不是有cron任务经常往本地发邮件这是个连锁问题。inode和块占用是两套不同的资源体系所以根分区空间没满但inode满了的情况也很常见千万别只盯着容量看。3. 清理实操从确认问题到解决3.1 安全清理journal日志并限制大小一旦确认journald是罪魁祸首清理就是一步到位的事。CentOS 7.9上我用得最多的是journalctl --vacuum-size它按总大小清理旧日志比手动删除文件安全得多journalctl --vacuum-size200M这个命令会把日志总占用压缩到200M以内保留的是最新的部分对排障来说完全够用。执行完之后再看一下journalctl --disk-usage确认效果。但清理只是治标真正要治本必须限制journald的上限。编辑/etc/systemd/journald.conf找到#SystemMaxUse这一行去掉注释并改为SystemMaxUse200M SystemMaxFileSize50MSystemMaxUse是整个日志系统可占用的总上限SystemMaxFileSize是单个日志文件的大小上限两者配合可以让日志块在写入时就受到约束不会无限制膨胀。改完配置文件执行systemctl restart systemd-journald生效。这里有个坑要提醒不要手贱去rm -rf /var/log/journal/*因为journald在运行中可能会丢失部分当前日志而且文件被占用时删除不会立即释放空间。用内置的vacuum参数才是正规操作。3.2 定位并释放deleted文件占用的空间对于lsof L1发现的deleted文件释放空间的做法取决于这个文件属于什么进程。如果是旧日志被logrotate切走但进程没释放重启一次对应服务即可systemctl restart rsyslog systemctl restart crond systemctl restart nginx重启服务会让进程重新打开日志文件旧文件的描述符随之关闭数据块也就释放了。如果是数据库、Java应用这类重服务持有已删除文件重启影响面较大就需要评估业务空窗期再操作。如果确实不知道那个deleted文件是什么可以先看完整信息lsof L1 | grep deleted ls -l /proc/PID/fd/FD/proc/PID/fd/FD符号链接会指向文件路径有时能看出是哪个软件创建的文件。在读完文件内容确认不需要之后再决定是否重启或kill该进程。不要一看到deleted文件就激动有些deleted文件反而可能是正在写入的关键数据乱搞会丢数据。3.3 清缓存、trash与yum缓存顺手把老备份也处理掉journal和deleted文件是最大的两个隐藏占用来源处理完它们之后顺手要做几件常规清理。第一个是yum缓存CentOS 7.9跑久了/var/cache/yum会堆积大量rpm包执行yum clean all这条命令会清掉缓存目录里的软件包腾出几百M到几个G不等。第二个是core dump文件位置在/var/lib/systemd/coredump/程序崩溃产生的core文件动辄几百M如果系统里某些服务经常crash这里会积累很多垃圾find /var/lib/systemd/coredump -type f -mtime 7 -exec ls -lh {} \;确认是旧core文件后直接删除即可。第三个是trash目录和临时文件/tmp、/var/tmp下超过7天没动过的文件基本可以清掉用find /tmp -type f -mtime 7 -delete这类命令时注意先加-exec ls -lh验证再删。还有一个很实际的经验如果你之前升级过opensshd这类软件操作时留下的rpm安装包、备份源码包、编译中间产物经常堆在/root下。升级opensshd到10.5的流程里很多人会先下载源码包、做好原配置文件备份这些文件往往就在/root目录日积月累就是好几个G。用du -x -h --max-depth2 /root查一下该删的删掉该打包归档的移到别处。4. 防患于未然让根分区不再轻易爆满4.1 日志切割与监控告警双管齐下清理干净只是解了眼前之急不把机制建立起来过阵子还会复发。CentOS 7.9默认有logrotate但它只处理受管日志很多应用自己的日志根本不在这个体系里。我建议把所有关键应用日志都接入logrotate配置模板大致如下cat /etc/logrotate.d/myapp EOF /var/log/myapp/*.log { daily rotate 14 compress delaycompress missingok notifempty copytruncate } EOFcopytruncate这个参数很重要适用于那些不重新打开日志文件的应用它会先复制一份再清空原文件避免因日志文件被替换而导致进程写入错乱。调整完配置可以用logrotate -d /etc/logrotate.d/myapp做一次预演验证。告警方面我没有用特别复杂的监控系统只是在crontab里加了一个磁盘告警脚本每天检查一次超过80%就发通知#!/bin/bash USAGE$(df / | awk NR2 {print $5} | tr -d %) if [ $USAGE -gt 80 ]; then echo $(date): root filesystem usage ${USAGE}% | mail -s Disk usage warning opsexample.com fi4.2 调整系统保留空间给LVM扩容留后路CentOS 7.9根文件系统默认保留5%的块给root用户维护用途这在根分区不大的机器上有点浪费。如果你的根分区就是几十G的LVM逻辑卷可以把保留比例调低tune2fs -m 1 /dev/mapper/centos-root执行完用df -h看一下可用空间会立刻增加几个百分点。但这不是让“空间变多了”而是释放了原本留给root维护模式的保留块适合根分区本来就紧张、你又对系统有足够掌控力的情况。更根本的办法是给LVM扩容。只要卷组里还有空闲空间就可以扩大根逻辑卷一步到位解决空间不够的问题# 查看卷组剩余空间 vgs # 扩大逻辑卷例如增加10G lvextend -L 10G /dev/mapper/centos-root # 扩容文件系统 xfs_growfs /CentOS 7.9默认根文件系统是xfs扩容时用xfs_growfs /拉满到逻辑卷全部大小不需要指定具体尺寸。如果你当初分区时用的LVM现在就能体会到它的好处了。但注意这一步必须在你确认物理磁盘还有空闲空间的前提下操作别盲目执行。5. 常见问题排查速查表与避坑实录5.1 隐藏占用现场排查清单把整个排查过程浓缩成一张速查表遇到问题时照着走一遍效率会高很多症状可能原因排查命令解决方法df -h显示100%du找不到大文件journald日志积累journalctl --disk-usagejournalctl --vacuum-size200M并限制SystemMaxUsedf -h满且lsof出现deleted文件进程持有已删除文件lsof L1重启对应服务或评估后kill进程df -h没满但写不了文件inode耗尽df -i查找小文件堆积目录清理或调优应用根目录下各目录都小但空间被占挂载点下层目录du -x /排除跨文件系统先卸载或进入挂载目录排查勿直接rm升级软件后根分区迅速爆满备份文件、缓存堆积du -sh /root /var/cache/yum删除旧rpm包、备份和core dump这五类是我实际运维中碰到的最高频场景前两类占了七成以上。如果你遇到的症状不在这张表里也别慌回到第1节从头查思路是一样的。5.2 操作过程中容易翻车的几个细节清理根分区看似简单实际操作中翻车的点特别多。第一个坑是不要在挂载点下面直接做du之外的盲目删除。比如/var/log如果单独挂载了另一个分区你在根目录下du -x会把它排除掉但如果你在/var/log下面清理时没注意挂载边界就可能误删数据。执行任何删除命令前先看一眼mount | grep /var/log确认边界。第二个坑是不要随便rm -f正在被占用的文件。有时候你觉得日志文件太大直接删了结果进程还持有旧文件描述符继续写入空间不释放反而造成“看不见的增长”。这种情况应该用logrotate的copytruncate或者重启进程。第三个坑和OpenSSH升级场景相关。CentOS 7.9上把opensshd升级到更高的版本需要先装一堆依赖包、编译源码、备份旧配置。很多人把/root/openssh-version目录里的编译产物和旧rpm包留着以为是“备份”结果一次升级能在/root下堆出2-3G。升级完成后这些源码包没有任何保留价值该清理就清理。第四个坑是aarch64架构的机器。如果你用的是CentOS 7.9 aarch64版本ARM架构排查根分区占用的思路完全一样但个别工具在ARM源里名字或路径略有不同。比如某个排查工具找不到时用yum provides */lsof这种命令在已安装的包里反查不要觉得是系统坏了。aarch64机器上yum源的软件包相对x86_64少一些有些软件得通过第三方源安装但排查命令本身没有区别。另外提醒一句处理完根分区100%之后最好重启一次机器或者至少重启相关服务。因为有些顽固的deleted文件只有在进程重启后才会释放有些服务对文件描述符的依赖在运行中也体现不出来。我之前排完一台机器du和df已经一致了但隔了一晚发现系统又在报磁盘满仔细一查原来是一个常驻进程还在写一个没发现的旧日志。所以清理完一定要用lsof L1复查一遍确认没有遗漏。5.3 清理完之后的验证动作空间释放出来之后我习惯按下面三步做一次完整验证df -h / du -x -h --max-depth1 / 2/dev/null | sort -hr | head -10 lsof L1 | wc -l第一步确认根分区剩余空间第二步确认可见目录的大小分布第三步确认没有遗留的deleted文件。如果df和du的差值在100M以内基本上算恢复正常。如果差值还是很大说明还有没找出来的隐藏占用回到第1节继续不要觉得奇怪。长期经验和直觉告诉我这类问题的核心技术点就是清晰理解文件系统层面和目录层面的统计差异然后针对不同差异成因做定向清理。以上这套流程我反复用了好几年虽然每次的具体场景略有差别但思路始终是一致的希望这篇能帮你少走几个弯路。