1. 磁盘快满了先分清df和du的职责边界1.1 一个常见的告警场景做运维和开发的朋友应该都经历过这种场景监控平台突然弹出告警说某台服务器的磁盘使用率超过90%甚至达到100%。你登上机器习惯性地敲下df -h看到根分区确实满了再敲du -sh /*挨个看根目录下每个子目录的大小加起来却比df显示的已用空间小了一大截。更让人抓狂的是明明du -sh /var/log只占1个G但df里显示根分区已经十几个G不知道去哪了。这种账对不上的情况十有八九会让人怀疑自己学了假的Linux命令。其实df和du这俩命令虽然都是查磁盘空间占用的但它们看问题的视角完全不一样。把它们的工作机制理解透了不仅排查问题快得多也能避免很多误判。1.2 df站在文件系统的角度看空间df全称是disk filesystem它统计的是文件系统层面的空间使用情况。你可以把它理解成查看整块硬盘的分区账本。当你执行df -h时看到的是每个挂载点对应的文件系统总共多大、用了多少、还剩多少。它是从文件系统的超级块和块组描述符里直接读取元数据所以执行速度非常快哪怕磁盘上有几百万个文件df也不会挨个遍历。df统计的已用空间不仅包含所有文件实际占用的数据块还包括文件系统的元数据inode表、块位图、inode位图、超级块副本等预留给root用户的保留块默认通常是5%日志文件系统如ext4的journal占用的空间已经被删除但还被进程打开的文件占用的空间。所以df反映的是整个文件系统层面真正不可用的空间这也是为什么当磁盘告警时我们第一个要看的一定是df。1.3 du站在目录树的角度看文件大小du全称是disk usage它统计的是目录或文件在文件系统里实际分配到的块大小。它的工作方式是递归遍历目录树逐个stat文件累加每个文件占用的磁盘块数。你可以把du理解成进入每个目录挨个翻账本把所有子目录和文件的大小加起来。因为du是遍历统计所以在目录层级特别深、文件特别多的路径上会非常慢。但它的优势也很明显能给出精确到每个目录、每个文件的大小方便我们快速定位到底哪个目录吃掉了大部分空间。需要特别留意du统计的文件大小是占用磁盘块的逻辑块大小而不是ls -l显示的那个文件逻辑长度。例如一个刚创建的空文件ls -l看到大小是0但du可能显示它占用了4KB或8KB因为文件系统分配磁盘空间时最少给一个块。反过来稀疏文件比如某些数据库文件、虚拟磁盘镜像在ls -l里看着明明有几十GBdu显示的实际占用可能只有几百MB因为它只有一部分块真正被写入过。1.4 为什么df和du统计结果经常对不上理解了上面的机制你大概能猜到为什么两者会有差异。总结一下最常见的几类原因原因df的表现du的表现已删除但仍有进程打开的文件显示空间被占用看不到这个文件因为目录项已删除文件系统保留块和元数据开销显示占用更高完全没统计这一块挂载点下隐藏的旧目录显示整个文件系统空间只显示新挂载内容挂载点本身边界硬链接文件按唯一inode统计空间实际只占一份数据块同一个inode被多次统计可能重复计算稀疏文件、压缩文件系统按实际分配块统计按实际分配块统计但和ls看到的大小可能相差很大所以遇到df和du对不上时不要马上断言哪个命令出错了这俩都没错只是统计口径不同。接下来的内容我会分别讲透这两个命令的实战用法以及如何把对不上的原因精确排查出来。1.5 判断该信谁两个工具的正确使用顺序我的建议是判断磁盘够不够用看df定位谁占用了空间用du。排查步骤永远是从df开始确认文件系统级别的状态再用du逐层查目录最后用lsof这类工具处理正常统计无法解释的差异。记住这个顺序能少走很多弯路。2. du命令的实际用法从目录总量到文件大小排行2.1 最常用的du选项速记du命令的选项不算多但足够灵活。先说几个必须刻进DNA的常用组合du -sh /dir以人类可读的格式显示目录总大小不列子目录。这里的-s是--summarize只输出总计-h是--human-readable自动选择K、M、G等单位。du -h --max-depth1显示当前目录下每个子目录的一级汇总大小。注意--max-depth和-s是互斥的用了-s再带--max-depth不会生效。du -a /dir显示目录下所有文件大小而不光是目录。du -h -d 2显示到二级子目录的大小。-d是--max-depth的简写比记--max-depth快。du -x跳过位于其他文件系统的目录只在当前文件系统内统计。这个选项在分析根分区时极其重要后面会专门说。du -b以字节为单位显示逻辑文件大小apparent size而不是实际磁盘占用。这个适合和数据库文件的大小做对比。实际工作里du -sh和du -h --max-depth1基本覆盖90%的需求。剩下的场景基本上都是拿它们配合sort做排行或者加--exclude排除某些大目录。2.2 查看目录总量与逐级拆解假设我们要查根目录下到底谁占了最多空间第一步肯定不是直接du -sh /*扫一遍虽然这个命令在服务器上最常用但根目录下往往挂着/proc、/sys、/dev这些虚拟文件系统直接扫会浪费大量时间还会得到一堆没有意义的数据。更合理的做法是df -h du -h --max-depth1 -x / 2/dev/null | sort -hr | head -20这里的-x告诉du不要跨文件系统这样就不会进入/proc、/sys、/dev这些挂载点。2/dev/null屏蔽掉没有权限访问的报错sort -hr按人类可读格式倒序排列head -20只取前20行。看到输出后找到了某个大目录比如/var占了40G那就继续往下一层du -h --max-depth1 /var 2/dev/null | sort -hr | head -20这样一级一级往下钻直到找到真正的大目录。这一步比较机械化但也是排查磁盘空间最稳妥的方法。2.3 大文件排行du结合sort的爽快姿势如果只想找大文件而不是慢慢翻目录可以用du -a把某个目录下的所有文件都列出来然后排序du -ah /var 2/dev/null | sort -rh | head -20这条命令会把/var下所有文件和目录因为-a会同时列出文件都算一遍然后按人类可读大小倒序排列。注意sort -rh能正确按K、M、G单位排序如果只用sort -rn会出现9G排在2M前面的情况因为字符串排序先比字母sort -rn虽然按数字比较但遇到9G和2M这种带单位的值时并不稳定。更推荐的做法是用find来找超过指定大小的文件因为du -a在文件数量极大时很慢find /var -xdev -type f -size 100M -exec ls -lh {} \; 2/dev/null | sort -k5 -hr | head -20-xdev同样是为了不跨文件系统-size 100M表示大于100MB-exec ls -lh {} \;把文件详细信息打出来然后按第五列大小列倒序排列。这个方法比du快很多因为find的-size条件是基于inode里的逻辑文件大小判断的不需要累加目录树。2.4 排除无关目录与避免跨文件系统遍历在实际服务器上有些目录是不需要统计的或者统计起来又慢又没意义。比如/proc、/sys、/dev这些虚拟文件系统永远不要用du去扫还有比如/var/lib/docker这种动不动几百万个文件的大目录如果只想看某个具体业务目录的大小就应该用--exclude忽略掉它du -h --max-depth1 -x --exclude/proc --exclude/sys --exclude/dev --exclude/var/lib/docker / 2/dev/null--exclude可以重复写多遍也可以配合通配符用。这里有个小技巧如果某个目录一直没有清理但你又暂时不能动它可以养成习惯把它加进du的黑名单里避免每次统计都要等它。-x这个选项为什么这么重要因为根分区下面经常挂着其他文件系统的挂载点比如/boot、/home、/data如果你不去限制du -sh /会把所有挂载点里的内容都算进来导致你看到的根目录占用其实是整个系统的总占用。用-x之后就只统计根文件系统本身这样才能和df /的结果对得上。2.5 du命令的重要进阶参数--apparent-size与block-size如果你在排查数据库或虚拟磁盘镜像时发现ls -l和du结果不一致需要理解du默认统计的是实际占用磁盘块的大小而不是文件逻辑大小。du --apparent-size统计的是后者也就是文件末尾字节数和ls -l看到的大小基本一致。比如# 生成一个100M的稀疏文件 dd if/dev/zero ofsparse.img bs1M count1 seek99 ls -lh sparse.img # -rw-r--r-- 1 root root 100M ... sparse.img du -sh sparse.img # 1.1M sparse.img du -h --apparent-size sparse.img # 100M sparse.img这个特性在判断文件是否真的占用了这么多空间时会很有用。比如你手里有一个100G的稀疏文件但实际磁盘占用可能只有几G迁移备份时完全可以通过cp --sparsealways之类的工具压缩体积。3. 排查经典疑难df和du结果对不上的几类元凶3.1 元凶之一文件被删除但进程未释放这是最常见的一种账对不上情况。某个进程打开了一个大日志文件你执行rm把它删了然后df一看空间竟然没释放。原因很简单在Linux中只要进程还持有这个文件的句柄即使目录项被删除文件占用的数据块也不会被系统回收。du在遍历目录时看不到这个已删除的目录项所以统计不到它但df是按照文件系统块位图来看的这块空间确实还被占用着。排查方法非常直接lsof | grep deleted或者在/proc下直接找ls -l /proc/*/fd/* 2/dev/null | grep deleted找到持有已删除文件的进程后根据情况重启服务或者kill掉进程空间立刻就能释放。如果服务很重要不能重启可以尝试用cp /proc/进程号/fd/文件描述符 /tmp/xxx把内容救回来然后从业务层面处理。不过绝大多数场景重启相关进程是最干净的做法。3.2 元凶之二文件系统的保留块与元数据开销ext4等文件系统会默认预留5%的块给root用户用来防止普通用户把磁盘彻底写满导致系统无法启动。所以你在df里看到的Use%已经包括了这些保留块。这个保留比例可以通过tune2fs -m调整比如想把/dev/sda1的保留比例改成1%tune2fs -m 1 /dev/sda1不过不建议在生产环境降到0%这是最后的兜底手段。除此之外文件系统的inode表、块位图、inode位图以及ext4的journal日志也要占用一些空间这些在du里是完全看不到的但加起来可能占几百MB到几个G不等取决于分区大小和文件数量。3.3 元凶之三挂载目录下的隐藏旧文件这个坑比较隐蔽。假设你有一个目录/data里面原本存了很多文件后来为了扩容量又加了一块新盘把新盘挂载到了/data上。挂载之后原来/data目录下的旧文件并没有消失它们只是被遮住了——从目录树上看不到了但那些数据块仍然被文件系统记录着。此时你在/data上执行du看到的只是新挂载盘的内容而df /看到的却是根分区里包含了那些被隐藏的旧文件的空间占用。排查方法也很简单# 查看某个挂载点。如果某个目录本身不是挂载点但在挂载了其他设备使用 df -h /data findmnt /data如果发现/data是一个挂载点而它以前的旧数据还占着根分区的空间可以用原来系统盘根目录下的/data路径来看但正常情况下是看不到的。这种场景最稳妥的办法是在挂载前先清空挂载点目录或者把旧数据先移到别处再挂载新盘。3.4 元凶之四硬链接、稀疏文件与压缩文件系统的统计偏差硬链接会让du对同一个inode重复计数。比如两个硬链接指向同一个大文件ls -l会显示两个条目du -a会把两个条目的大小都累加进去但实际文件系统只分配了一份数据块。所以在有大量硬链接的备份目录或快照目录下du统计出来的总大小会比df显示的已用空间大。遇到这种情况可以用find /dir -type f -links 1找出硬链接数量大于1的文件确认是不是它们导致统计虚高。如果虚高很严重甚至可以改用df来判断真实占用因为du受硬链接影响太大。稀疏文件的问题在2.5已经提过这里不再重复。压缩文件系统比如btrfs的压缩选项、ZFS的压缩功能也会导致du和实际磁盘占用对不上因为一个文件的逻辑大小可能是1M但压缩后只占64K的数据块du统计的恰恰是压缩后的实际块大小。ls -l则是逻辑大小所以两者不一致是正常的。3.5 排查思路小结一条命令看diff如果你不想记这么多原理遇到对不上的情况先执行下面这条命令df -h / df -h / | awk NR2 {print df统计已用空间: $3} du -shx / 2/dev/null lsof L1lsof L1会列出所有已删除但还在被占用的文件其中SIZE列就是占用空间的大小。大多数情况下从这里能看到答案。如果lsof输出为空再考虑元数据和保留块的问题或者用dumpe2fs查看文件系统的详细信息dumpe2fs -h /dev/你的根分区 | grep -i block count\|reserved block count\|free blocks算一下保留块占全部块的比例就能对上差额了。4. 实战案例根分区快满时快速定位占盘元凶4.1 从一张告警截图开始假设有一台生产服务器监控告警显示根分区使用率95%。这台服务器上跑着Nginx、MySQL和几个Java应用根分区是200G。我们登录后第一步先看整体状态df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 200G 190G 3.5G 95% / devtmpfs 3.9G 0 3.9G 0% /dev /dev/sda1 487M 143M 309M 32% /boot根分区已用190G可用只剩3.5G。接下来我们进根目录做逐级下钻。4.2 第一轮排查从根目录逐层du使用du扫描根目录并跳过其他文件系统du -h --max-depth1 -x / 2/dev/null | sort -hr | head -15 76G /var 68G /opt 29G /usr 8.2G /home 4.1G /srv 1.2G /root .../var和/opt是大头加起来已经140多G。继续下钻/vardu -h --max-depth1 /var 2/dev/null | sort -hr | head -15 40G /var/log 22G /var/lib 8.5G /var/cache/var/log占了40G这不太正常。往下看du -h --max-depth1 /var/log 2/dev/null | sort -hr | head -10 28G /var/log/nginx 6.2G /var/log/mysql 3.1G /var/log/syslog原来访问日志和错误日志已经积累了这么多。这一轮排查基本就能锁定目标了。4.3 第二轮排查用find找大文件如果du逐级下钻太慢或者想知道具体有哪些大文件可以直接用find找find / -xdev -type f -size 500M -exec ls -lh {} \; 2/dev/null | sort -k5 -hr | head -20 -rw-r----- 1 root admin 28G /var/log/nginx/access.log -rw-r----- 1 mysql mysql 6.2G /var/log/mysql/error.log -rw-r----- 1 root root 3.1G /var/log/syslog -rwxr-xr-x 1 root root 1.8G /opt/backup/app-full-2024.img相当于上一轮du的结果在文件级得到了确认。注意到/var/log/nginx/access.log有28G这个日志明显没有做切分一直在单文件里写。4.4 第三轮排查结合lsof检查已删除未释放文件此时先别急着rm先考虑有没有进程还持有已删除的大文件。在真实场景里经常是前一天有人清了日志但磁盘空间却没降下来。我们用lsof L1查一下lsof L1 | head -20 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME nginx 1234 root rw REG 253,2 26G 0 52345 /tmp/access.log.1 (deleted) mysqld 2345 mysql rw REG 253,2 6.1G 0 38821 /var/lib/mysql/undolog.bin (deleted)果然Nginx拿着一个已删除的日志文件句柄可能是之前日志被切割后进程没有重建文件它占着26G没释放MySQL也有一个删除的undo文件占着6.1G。这就是为什么du统计所有目录加起来只有150G但df显示用了190G的差异来源。处理方法是让Nginx重新打开日志文件或者重启服务释放句柄kill -USR1 cat /var/run/nginx.pid # 或者更简单地 nginx -s reload对于MySQL如果删除的undo文件还在被持有通常需要重启MySQL实例或者让它正常旋转undo日志空间才会真正释放。尽量不要直接kill进程先看是不是业务高峰避免影响线上。4.5 安全清理技巧日志文件用truncate而不是rm清理日志文件时很多人习惯性地rm掉再重启服务这样虽然可行但存在两个问题一是如果进程持续写这个日志文件rm之后文件句柄仍然存在空间不会释放二是重启服务可能造成短暂中断。更好的做法是直接清空文件内容而不删除文件truncate -s 0 /var/log/nginx/access.log或者用老派的 /var/log/nginx/access.log。这样做的好处是Nginx继续持有同一个文件inode没有变化文件大小变为0空间立即释放也不需要重启进程。很多日志服务logrotate实际上也是用类似思路处理的。如果还想保留部分日志做问题追溯可以先切分再清空cp /var/log/nginx/access.log /var/log/nginx/access.log.old truncate -s 0 /var/log/nginx/access.log注意cp会复制整个文件到别处写IO较大生产环境可以换用mvmv /var/log/nginx/access.log /var/log/nginx/access.log.$(date %F) kill -USR1 cat /var/run/nginx.pidUSR1信号会让Nginx重新打开新的日志文件这是比较标准的切割手法。4.6 避免再次告警的几条经验日志清理不能等到磁盘满了才动手。我在实际项目里至少会设置两层防线配置日志轮转logrotate按天或按大小切分保留最近N份超过自动压缩和删除。以Nginx为例在/etc/logrotate.d/nginx里写一段配置即可。写一个定时任务cron每天扫描根分区的使用率如果超过85%就发告警到钉钉/企业微信。用df -h / | awk {print $5}取百分比加个判断就行。另外/opt下面那个1.8G的镜像也是可以清理的冗余产物但要确认没有在用的备份计划后再删。5. 深入原理df与du的底层差异和高效使用建议5.1 文件系统块分配 vs 目录项遍历理解这两个命令的底层差异能在排查时少走很多弯路。df读的是文件系统的元数据块它查到的是所有已被分配的数据块总数减去空闲块数因此它无法告诉你这些块被哪些文件占着。du则是从根或指定目录开始读取目录项对每个文件执行stat()获取文件的st_blocks即占用的块数量然后递归累加。由于du是从目录项出发它天然看不到已经被删除目录项不存在但仍然被占用的文件由于stat()获取的是文件inode里的块数而不是精确到每个目录项所以同一个硬链接被多个目录引用时du在递归过程中会在每个目录里都算一次导致重复统计。反过来稀疏文件的st_blocks小于逻辑大小du统计的结果自然就比ls -l小。5.2 为什么du在/proc、/sys上看到的不是真实占用/proc和/sys是虚拟文件系统内核动态生成目录和文件数据。如果你对着/proc跑du -sh /proc会得到一个巨大但毫无意义的结果因为这里面的文件大小基本都是0虚拟文件但du会继续递归遍历造成极大的性能损耗。所以任何用du扫描根目录的常规操作都必须配合-x跳过这些挂载点。另外/dev/shm默认是tmpfs它使用内存作为存储严格来说也不算磁盘空间。df -h /dev/shm可以看到它的大小默认是物理内存的一半。如果你发现df里某个tmpfs满了要小心它吃的是内存清理它并不会影响磁盘剩余空间。5.3 inode耗尽比磁盘空间占满更隐蔽的故障当你部署一个应用创建了大量的小文件比如消息队列的临时文件、Docker的容器层、邮件系统的邮件存储可能出现磁盘明明还有几十G空闲但创建文件时报No space left on device。这种情况往往是inode耗尽了。df -i可以查看inode使用率df -i Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda2 1310720 1310720 0 100% /这里的inode耗尽说明文件系统里的索引节点数量用完了和块空间完全是两码事。排查时可以用find / -xdev -printf %h\n | sort | uniq -c | sort -k1 -rn | head来找哪个目录下小文件最多。清理掉一批无用的临时文件就能恢复。5.4 日常巡检定时记录du快照并分析增长趋势光靠出现告警再上机器排查是被动式运维。更合理的方式是每天记录一次关键目录的大小连续观察一周你就能看到空间增长最快的是哪些目录。比如写一个简单的cron脚本du -h --max-depth1 -x /var /opt /home 2/dev/null | sort -hr /var/log/du_daily_$(date %Y%m%d).txt或者用du -sh几个核心目录存到Prometheus等监控系统里。当某个目录的大小曲线明显抬头你就能提前处理而不是等磁盘满了再满世界找元凶。我个人习惯同时记录df -h /和du -shx /的差值如果这个差值持续增大往往说明有进程长期占着已删除文件需要关注服务是不是需要重启了。6. 实用命令对照表与个人经验总结6.1 命令速查对照表下面这份表格是我平时最常用的场景化命令直接抄作业就行目标命令说明查看磁盘空间总体使用df -h最直观看Use%查看inode使用情况df -i小文件多时必看查看当前目录总大小du -sh .最常用查看所有子目录大小du -h --max-depth1 .注意排序用sort -hr查看根分区各目录大小不跨盘du -h --max-depth1 -x / 2/dev/null根分区排查第一步查找大于100M的文件find / -xdev -type f -size 100M -exec ls -lh {} \;-xdev防止跨盘查找前20个大文件find / -xdev -type f -size 100M -print0 2/dev/null | xargs -0 du -h | sort -hr | head -20比-exec ls更准确统计块大小查看已删除未释放空间的文件lsof L1最直接查看某个进程打开的文件lsof -p PID排查进程占用清空大日志文件truncate -s 0 file不删除文件立即释放空间排除某些目录统计du -h --exclude/proc --exclude/sys /按需加-x6.2 我踩过的三个du/df小坑第一个坑在目录末尾加不加斜杠du显示结果可能一样但在sort -hr排序时没问题可如果你写脚本解析du的输出去做告警最好固定用绝对路径避免相对路径造成误解。第二个坑du -s和du -sh的区别。有些人习惯写du -s /data输出结果是一串纯数字单位是KB服务器上可能数值巨大不方便读。再加上-h后输出的是5.4G这种人类可读格式。但如果脚本里需要做数值比较建议用du -sk或du -sm避免-h输出的单位字符串干扰判断。第三个坑用ls -lh看到文件100G但服务器磁盘一共才50G以为出Bug了。这种通常就是稀疏文件或压缩文件系统导致的用du -h确认实际占用不必慌张。另外提一句du -x和find -xdev是同一个思路限制在当前文件系统内。但du的-x只对命令行参数指定的目录生效对于参数里的目录本身即使它是挂载点也会统计它的内容。所以du -x /不会统计/data如果/data是独立挂载点但如果你执行du -x /data它会在/data里正常统计。这个细节在写脚本时要特别注意。6.3 最后推荐一个交互式利器ncdu如果你经常需要手动排查磁盘占用强烈建议安装ncduNCurses Disk Usage。它本质上是du的交互式版执行ncdu /之后会先快速扫一遍目录然后给你一个可以上下翻、按大小排序、进入子目录、甚至直接删除文件的界面。比一条条du命令来回敲效率高很多。# Debian/Ubuntu apt-get install ncdu # CentOS/RHEL yum install ncdu使用很直接ncdu -x /参数-x同样表示不跨文件系统。进入界面后方向键选择目录回车进入子目录d可以删除当前选中的文件或目录会二次确认s按大小排序q退出。我第一次用它清理一个磁盘告警的服务器总共只花了三分钟就找到了罪魁祸首比用du和find组合命令快得多。不过有一点要注意ncdu扫大目录时也需要一定时间但它比du强的地方在于能交互式下钻不用每次把整个目录树重新扫一遍。在实际运维工作中df和du就像左手和右手df告诉你系统还有没有救du告诉你问题出在哪个角落。把这两个命令的机制和组合技巧吃透再加上lsof和find这两把辅助工具不管磁盘告警多狠你都能稳住阵脚快速定位并解决。以后如果再遇到df和du打起来的情况别急着站队先冷静想想是文件被占用、保留块作祟还是挂载隐藏或者硬链接重复统计挨个排除空间自然就水落石出了。