“根目录空间不足”这个告警凡是做服务器运维的人早晚都会撞上。尤其是当你手里管着几台CentOS 7或者Ubuntu虚拟机某天登录上去准备照常部署服务结果发现命令敲下去就报错连日志都写不进去系统里到处飘着“No space left on device”。这种时候如果你还不太清楚根目录和磁盘分区之间的区别很可能会在排查的路上绕很久。这篇文章就围绕“检查根目录空间”这件事把从最基础的查看命令到定位大文件、清理垃圾、给根分区扩容、排查疑难问题的完整链路都讲一遍。适用对象不只是专职运维也包括自己折腾Linux虚拟机、搞Android开发时发现SD卡根目录无法授权、开Word提示“内存或磁盘空间不足”这类桌面环境问题的普通用户。内容不涉及复杂底层原理更多的是大家实际踩坑后的经验汇总按步骤操作一般都能解决。1. 先搞明白根目录空间为什么总是最先告急在日常工作中我见过不少新手一上来就执行df -h /看到使用率90%就直接慌了然后漫无目的地删文件。但真正要解决“根目录空间不足”先得弄清楚根目录在这台机器上究竟处于什么位置以及它为什么那么容易被塞满。1.1 分区、挂载点和目录三者经常被搞混很多“根目录空间不足”的排查过程之所以绕弯路就是因为在概念上把分区、挂载点、目录这三件事黏在了一起。磁盘接入系统后我们会对它做分区比如一块500G的硬盘可以划分成/dev/sda1、/dev/sda2。但分区本身是不可以直接使用的系统需要把它挂载mount到某个目录上这个目录就被称为挂载点。比如提前规划好的场景下/dev/sda1挂载到/boot/dev/sda2挂载到//dev/sda3挂载到/home。你平时看到df -h输出里的每行记录本质是某个文件系统也就是已格式化并挂载的分区的使用情况。所以当我们说“检查根目录空间”真正检查的对象是挂载到/目录的那个分区而不是路径/本身。路径/只是一个入口只要系统在运行它一定存在但承接它背后数据的那个文件系统如果满了访问就会出问题。这个区别很重要因为它决定了排查时该去df看挂载点而不是拿du去扫陌生目录。另外有个非常常见的误导点你以为某个目录的数据在根分区下实际上它可能被单独挂载到另一块磁盘上了。比如很多公司会把/home、/data、/var/lib/mysql单独挂载因为它们的增长量非常可预测。当你发现根目录空间快满了先去看一眼挂载情况别急着删根分区下的文件避免删完发现根本没删到正主。1.2 根目录被塞满的常见“元凶”做过一段运维的人都会有这种体会根分区只要规划时没留够余量用满只是时间问题。从实际经验看最常见的填充来源集中在下面几类一类是各类日志文件。系统日志、应用日志、容器日志、数据库日志增长速度快得惊人。比如一个没有配置日志轮转的Nginx访问日志高峰期一天写几个G不是新鲜事Java应用如果不做日志切割一次异常反复打印堆栈几天就能把分区写满。另一类是软件包缓存和临时下载文件。CentOS 7下yum默认会把下载的rpm包缓存在/var/cache/yumUbuntu下apt的缓存在/var/cache/aptDocker镜像和容器日志默认都堆在/var/lib/docker还有临时目录/tmp里的文件看起来不起眼但例如一个长期运行的脚本崩溃前留下的几G临时转储文件就能把空间耗掉一大截。还有一类是用户数据误放到系统分区。比如有的应用默认把数据写入/opt有的数据库直接装在根分区下有的同事习惯把大文件解压到/root或/tmp再转移结果一次性文件堆积多了根分区就被吃满了。搞清楚这些“元凶”会直接影响后续清理的路径选择别一上来就盯着日志目录删先把盘子里的数据分布看清楚再动手。2. 五分钟定位根目录空间消耗大户检查根目录空间这件事看起来简单就是看一个使用率数字但深入一点你需要回答两个问题当前可用空间还剩多少根目录下到底是哪些目录吃掉了空间别觉得这两个问题是一回事分区使用率只告诉你结果目录占用明细才能指导你下一步动作。2.1 第一手检查df命令的完整解读最基础的命令是df -h。-h参数让输出以人容易读懂的格式显示比如K、M、G这样的单位实际执行后你看到的结果像这样Filesystem Size Used Avail Use% Mounted on /dev/sda2 50G 47G 2.1G 96% / tmpfs 3.9G 0 3.9G 0% /dev/shm这一行信息里Size是分区总大小Used是已使用量Avail是当前用户可用的空间Use%是使用比例Mounted on是挂载点。我一般会顺手多加几个参数df -hT里的T用来显示文件系统类型因为ext4、xfs、overlayfs的处理方式在不同场景下是有区别的df -i则是查看inode使用情况这是很容易被忽略的一点后面单独讲。一个比较容易被忽略的操作是检查根目录空间的时候别只盯着挂着/的那行最好顺手看下所有挂载点的使用率。这能帮你确认一个问题——根分区满了别的地方还有富余吗如果/home挂载在独立分区且有大量空闲那你清理策略的重心就可以放在迁移数据而非删除数据上如果所有分区都快满了那就真要考虑扩容或者加盘了。另外补充一个细节root目录下的空间和普通用户目录下的空间很多时候并不是同一块区域。当/home被独立挂载到专门的数据盘时普通用户文件写满那个盘和根分区并没有直接关系反过来也是一样。所以每次做根目录空间检查我都会强调“先看清挂载结构再谈空间状况”。2.2 用du命令快速定位谁占了你的根目录df告诉你的是结果du才能告诉你原因。定位根目录下哪个子目录占用最多常用的是下面这条du -h --max-depth1 / 2/dev/null | sort -hr | head -20--max-depth1的意思是只显示/直属下第一层子目录的大小不会无限往深层递归这样输出的结果一眼就能看完。sort -hr是按人类可读数值反向排序占空间最大的目录排在最上面这是一个很顺手的小技巧因为du默认输出顺序是随机的直接配sort才能看得舒服。2/dev/null则是把权限不足一类的报错丢掉避免刷屏。执行完成后你会看到类似这样的输出18G /var 12G /usr 5.2G /home 2.3G /opt 1.8G /root这时候思路就清晰了接下来钻进/var这个目录继续执行同样的套路逐层往下剥。绝大多数情况下三层以内就能找到真正的“空间刺客”。这里要提醒一下du扫描大目录会花一些时间比如/下如果有海量小文件可能要跑几十秒甚至几分钟。有些朋友遇到根分区快满时急着要结果看到扫描慢就不耐烦其实可以缩小范围比如怀疑是容器日志就直接du -h --max-depth1 /var/lib/docker/containers 2/dev/null | sort -hr | head指向性更强速度也快得多。实际排查中还有个高频场景你删了很多日志却发现空间没释放。这个问题的原因之一是删文件时对应进程还开着句柄也就是文件虽然从目录里移除了但进程仍然占着它空间要等进程释放才会归还。这种情况最典型的就是删除了一个正在被Java进程写入的日志文件明明du看到文件不见了df却显示空间一点没少。解决办法是找到那个文件对应的进程并重启它或者直接lsof | grep deleted查一下哪些是已删除但仍被占用的大文件。2.3 inode被占满的隐蔽情况有些时候根分区的df -h显示还有几十G可用但应用就是报“No space left on device”甚至创建文件都失败这种诡异现象十有八九是inode耗尽了。Linux文件系统存储文件时除了数据本身还需要记录文件元数据例如权限、属主、大小、时间戳等。这些元数据存放在一个叫inode的结构里。每个文件和目录都会占用一个inode分区容量固定inode数量也是格式化时就算死的。如果分区里塞满了大量小文件比如某个程序生成了几百万个缓存小文件、邮件系统的邮件队列堆积那么即使总字节数没超过分区容量inode可能已经先用完了。检查方法非常直接执行df -iFilesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 3276800 3276780 20 100% /看到IUse%到了100%就基本可以锁定是inode耗尽。继续定位的方式和之前类似用du找大目录但真正要找的是“文件数量最多”的目录此时可以用find来辅助find / -type f -printf %h\n 2/dev/null | sort | uniq -c | sort -rn | head -20这段命令会把所有文件的所在目录统计出来按文件数量倒序排列很快能找出程序疯狂创建小文件的目录。找到后用确认清理即可。提示inode耗尽的现场通常发生在邮件系统、消息队列、缓存类应用上。清理时如果只是删一条队列里的消息批量删除建议用find /目录 -type f -delete如果文件数量极大一条条删会等到天荒地老。3. 根目录空间不足后的两条路清理与扩容如果是临时告警优先做安全清理如果是业务持续增长导致的常态问题那就得做扩容。这两条路线针对不同情况很多人只走其中一条导致过段时间又满这次我给一个完整的选择框架。3.1 安全清理日志、缓存与临时文件一手抓在动手清理前强烈建议先看一眼有没有正在写入大文件的进程避免做无用功。可以通过lsof L1找出那些被删但仍被占用的文件如果有先处理对应进程。清理顺序我按安全性从高到低排一下亲测有效第一类最安全也最该优先清理的是各类缓存。CentOS 7下执行yum clean allUbuntu下则是apt-get clean rm -rf /var/lib/apt/lists/*这两条命令清理的是系统更新时下载的软件包缓存不会影响已安装的软件清理出来的空间视机器使用频率而定少的几百M多的时候能到几个G。第二类是系统日志。但注意日志不能直接一股脑全删生产环境的日志有时候还有追溯排查价值。更稳妥的做法是找到一个日志量最大的文件确认里面的内容不再需要追溯后清空它而不是删除它。原因很简单相关进程还可能继续在写这个文件如果删了它进程不会自动重建反而可能造成异常 /var/log/messages journalctl --vacuum-time3djournalctl --vacuum-time3d这条尤其值得记下来它只保留最近3天的systemd日志之前的总量大清理后的效果非常明显。对于旧日志也可以提前配置logrotate让日志按天分割、按数量保留这个在文末会提。第三类是Docker垃圾这个经常是根分区爆满的主因。在一台装了Docker且频繁更新镜像的机器上镜像和容器日志占掉几十G非常正常docker system prune -a这条命令会清理所有未被容器使用的镜像、网络和构建缓存执行前它会提示你确认。如果只是想清理日志文件可以进到/var/lib/docker/containers/*/目录看那些*-json.log文件直接清空对应日志即可cat /dev/null /var/lib/docker/containers/容器ID/容器ID-json.log第四类是/tmp和/var/tmp目录。长期运行的机器上总是堆了一些临时文件重启相关服务后不再被引用的临时文件就可以清掉。需要提醒的是别手滑用rm -rf /这种恐怖写法建议只清空指定目录find /tmp -type f -atime 7 -delete-atime 7表示访问时间在7天前的文件这条命令执行前最好先find /tmp -type f -atime 7 | wc -l统计数量确认没误伤当前正在使用的临时文件。3.2 动态扩容给CentOS 7和Ubuntu虚机扩展根分区如果清理完之后空间使用率还是长期维持在80%以上就说明这台机器容量规划本身有问题与其反复清理不如直接扩容。这里分两种常见情况一种是虚拟机场景比如VMware、KVM下挂载的虚拟磁盘另一种是云主机场景通过控制台扩容云盘。核心步骤其实是相通的。先说底层逻辑。大多数Linux安装时默认采用LVM管理分区也就是把物理分区PV加入卷组VG再在卷组上切出逻辑卷LV最终格式化并挂载。所以扩容的链路是先扩充物理磁盘 - 让系统识别到新空间 - 扩充PV - 扩充LV - 扩充文件系统。每一步执行完成后都可以通过对应命令验证空间是否生效。举一个CentOS 7虚拟机扩容根分区的典型例子。假设根分区对应的逻辑卷是/dev/mapper/centos-root卷组名是centos执行前先确认现状df -h / vgdisplay pvdisplayvgdisplay里能看到卷组当前空闲空间Free PE / Size如果空闲空间有富余直接走“扩充LV”这一步即可如果没有就先加物理磁盘然后执行pvcreate把新磁盘加入卷组。虚拟机加盘后在系统里未必马上出现可以执行partprobe或者直接重启让系统识别。扩容逻辑卷的命令如下lvextend -l 100%FREE /dev/mapper/centos-root这条命令把卷组里所有剩余空间全部划给根分区对应的逻辑卷。但到这一步还没结束系统分区并不会自动变大还要让文件系统感知新空间。ext4和xfs的方法有区别CentOS 7默认可能是xfsxfs_growfs /如果根分区是ext4则执行resize2fs /dev/mapper/centos-rootUbuntu下的流程基本一样区别只在于卷组名和逻辑卷名的具体值不同执行lvdisplay就能看到当前VGT和LVT名称套进去即可。扩容完成后用df -h /复查逻辑卷容量和文件系统容量应该都变大了。注意执行扩容操作前强烈建议先给虚拟机打快照或做数据库备份。虽然LVM扩容本身风险不高但这件事情属于底层磁盘操作万一中间断电或操作失误数据安全永远要放在第一位。3.3 桌面环境与开发工具的特殊场景标题热词里还有一个容易被忽略的部分当你电脑的分区满了桌面应用也会出各种奇怪问题比如热词里提到的Word提示“内存或磁盘空间不足无法显示所请求的字体”Android Studio无法对SD卡根目录授权微信的文稿数据在根目录堆积等等。这些场景其实归结为一个共同点它们的临时文件、缓存、用户数据大多存放在系统盘Windows下是C盘Linux桌面环境下挂在根目录。以Windows为例如果C盘空间耗尽Word这类应用连临时文件都创建不出来于是给出“内存或磁盘空间不足”这种看起来莫名其妙、其实只是因为临时落盘失败的报错。这时候一般先清理%TEMP%、C:\Windows\Temp再把微信文档图片缓存、Android SDK缓存清理一下重新启动软件基本就恢复正常了。如果你在系统设置里看到“压缩此驱动器以节约磁盘空间”的选项我个人的经验是不要对系统盘开启压缩尤其是SSD开启后性能下降明显空间收益却很有限真正治本的办法还是把个人用户目录迁移到其他盘符。Android开发中“无法获得SD根目录授权”的问题也比较典型。新版本Android对存储权限收得很紧应用不再自动拥有访问SD卡根目录的权限需要去系统设置里手动开启“所有文件访问权限”或“USB存储”权限。这和磁盘满没有直接关系但如果你在Android Studio连接设备时刚好遇到设备存储空间不足授权窗口也常常弹不出来卡在一个类似“无法完成操作”的状态。这时候先连接设备清理存储空间再重新打开授权页通常就能正常走通了。4. 实操中容易踩进去的坑和对应解法前面讲了不少命令和流程这一节把我在一线运维中反复踩过、也看到同事踩过的坑集中整理一下。这些坑不看文档的话很难一个晚上绕过去因为它们大多不是报错信息本身有误导而是现象和原因之间存在一层“中介变量”。4.1 文件删了空间却没释放到底为什么这是最经典的一个问题日志目录已经删掉了好几个G的文件df -h显示根目录使用率纹丝不动。我在之前提过原因这里展开讲一下处理套路。当你执行rm删除文件时如果某个进程已经打开了这个文件且离不开它比如日志文件、临时数据库文件文件系统会把这个文件标记为已删除但实际的磁盘块直到该进程关闭文件句柄后才能释放。你用ls或du检查目录时看不到这个文件但它的物理空间仍被占用。排查手段是lsof | grep deleted输出结果里会看到删除文件的进程PID和文件路径对进程服务类的文件重启服务即可释放如果对应进程已经不必要了杀掉进程更直接。还有一种更隐蔽的是数据库进程在数据文件被“删除”后仍在持续写入那么重启数据库前请先确认事务完整性否则容易带来数据丢失风险。4.2 盲目清理导致误删关键目录清理空间这件事本身相对安全但选错目录就另说了。我见过有人为了腾空间直接把/var/log整个目录删了以为只是日志结果服务起不来也见过有人对/run目录下手导致系统莫名其妙出现各种异常状态。正确的姿势是先du --max-depth1逐层进入找到具体文件再处理。清理时尽量以“清空文件内容”代替“删除文件本身”。比如/var/log/messages如果还要用应执行 /var/log/messages清空而不是rm。系统目录里有大量文件在创建时并没有考虑“被删除”的情况删了之后重启才能发现少了依赖那时再修复就麻烦得多。4.3 扩容后显示空间没变化的排查思路扩容操作本身执行完了结果df -h /还是旧容量常见原因有以下几种第一扩容的是物理磁盘但新空间没有创建PV或者没有加入VG。执行lsblk看磁盘大小再执行pvdisplay看PV大小如果PV本身没变说明LVM根本不知道新空间存在需要先parted或fdisk调整分区表再pvresize /dev/sdX让PV感知新空间。第二LV扩了但文件系统没扩。比如我上面说的xfs用xfs_growfsext4用resize2fs少执行一步文件系统容量就不会变。太常见了甚至老手也偶尔会漏。第三系统里存在多个逻辑卷你扩容的LV并不是/实际挂载的那个。这就又回到我开头强调的“先弄清挂载结构”这点上。出现这种状况多半是机器上装了多个系统或者有多块系统盘执行挂载路径时选错了目标。每次扩容前用df -h /和lsblk -f双向确认就能避免。4.4 监控里的“缓存占用”那是无法直接清理的吗有时候你去看文件空间使用率发现df显示已用空间很大但用du把所有目录加起来数字对不上多出来几个G甚至十几个G。这通常是因为大文件在被进程持续写入时文件系统已经分配了空间但du只统计到被目录引用的块两者统计口径不同。还有一种常见情况是挖矿脚本、木马程序或某个失控进程在后台疯狂产生临时文件你删完一批它又写一批空间使用率短时间就回来了。这种时候不要只顾着清理先看进程列表top里CPU占用异常、lsof L1后能看到可疑进程优先处理进程本身否则清理永远只是安慰自己。5. 把根目录空间管起来日常检查的正确方式前面所有内容都在处理“已经满了之后的急救”但优秀的运维习惯应该是把问题消灭在“还没满”的阶段。这里分享一些我日常使用的方法不一定多高大上胜在简单有效。5.1 用一条命令快速判断根目录健康度现在我每台新机器上线都会先配一个简单的检查脚本核心就是df加阈值判断threshold80 used$(df -h / | awk NR2{print int($5)}) if [ $used -gt $threshold ]; then echo Warning: root partition usage is ${used}% fi写成脚本后放进crontab每天跑一次或者配合监控系统做告警。比如*/30 * * * * /usr/local/bin/check_root_space.sh这么做的好处是告警发生的时机提前了给自己留足处置时间不用每次都从90%以上的高危状态开始救火。另外需要说明的是这条脚本只是帮你看当前状态如果是判断增长趋势建议把每天的df -h /输出重定向到一个文件里积累一两周就能看到趋势辅助判断是真增长还是偶发波动。5.2 提前配置日志轮转避免日志无限膨胀大部分日志撑爆根分区的案例其实可以通过配置logrotate来提前规避。Linux自带logrotate工具系统日志的轮转配置一般在/etc/logrotate.conf和/etc/logrotate.d/目录下。给应用日志增加一条配置示例/var/log/myapp/*.log { daily rotate 7 compress missingok notifempty copytruncate }daily表示按天轮转rotate 7表示保留7份日志compress对旧日志做压缩copytruncate适合进程锁定日志文件的场景它通过复制截断的方式避免重启应用。Docker容器日志虽然不走系统logrotate但也可以在Docker的daemon.json里配置log-opts: {max-size: 20m, max-file: 5}做限制。配置好后可以执行logrotate -f /etc/logrotate.conf手动测试一遍确认轮转效果符合预期再放到线上。5.3 何时清理何时扩容我的判断标准实践中我给自己定了几条简单规则分享出来供参考如果根分区使用率低于80%只需要留意增长趋势偶尔做做定向清理。如果使用率在80%到90%之间建议做一轮常规清理日志、缓存、Docker垃圾同时排查是否有异常增长的应用。如果使用率超过90%优先安全检查是否有进程占用未释放空间之后果断扩容不要长期让分区处于高水位因为这类机器一旦业务量突然上来很快又会触发新一轮告警。这里想多说一句自己的判断依据扩容本身并不复杂并不是每次都需要扩容比如还在80%以下徘徊就别折腾底层磁盘了。但到了90%以上扩容大概率比反复清理更划算因为清理一次的成本时间、误删风险已经超过了扩容成本。5.4 日常小技巧给根目录空间做体检时顺手养成的习惯最后补充几个我在实际检查中养成的习惯它们更像“肌肉记忆”关键时刻能少走很多弯路。第一用lsblk -f看文件系统类型。别以为你记得每台机器根分区是ext4还是xfs就能大意环境变了、磁盘换过、挂载方式调整过实际处理扩容命令会完全不同这个习惯能省掉试错。第二清理之前先看一眼挂载点。特别是find / -type f -size 100M这类全盘扫大文件命令很可能扫到/mnt、/media下的挂载盘那里虽然从/路径下看得到但空间根本不属于根分区扫出来的结果会误导你。如果只关心根分区把命令限制在非挂载子目录范围内最稳妥。第三检查脚本里加一行df -i /的输出。很多人只看容量不看inode等报错时才发现是inode满。加进去之后成本很低但能提前暴露出很多潜在问题。写在最后的一点体会做了这么久运维我最大的感受是根目录空间告警不是单纯的“删文件”或“加磁盘”的问题它更像是系统运行健康状态的一个晴雨表。你清理掉了日志为什么还会反复满到底是谁在持续写入是应用没配轮转还是某个服务在泄露文件句柄这些才是真正值得关注的底层原因。按我自己的经验每次处理完告警后别急着收工花十分钟把“为什么满”和“以后怎么防”想清楚下次才会更轻松。如果你手上正好有台CentOS 7或者Ubuntu虚拟机建议先跑一遍第一节和第二节里的命令熟悉一下df、du、lsblk的输出格式。不用背命令多敲几遍自然就记住了。真遇到扩容场景记得先打快照再动手稳字当头总没错。