开机第一件事我一般会敲一条df -h看看磁盘还有多少底仓。不是夸张Linux服务器上最不缺的报错就是No space left on device而真正把磁盘占满的往往不是某个大文件而是你没注意过的日志、临时文件或者已经删掉但还被进程咬住的空间。df命令看起来只是打印一堆数字但用好了它能直接告诉你系统还能撑多久、该不该扩容、哪个挂载点在报警。这篇就专门聊df的实操用法从基本输出到排查套路把每个参数什么时候该用、怎么组合说清楚。1. 先看懂df输出里的每一列磁盘管理的第一手数据第一次接触df的人最容易犯的毛病是只看Avail那一列或者干脆只扫一眼Use%看到50%就放心。这几个数字背后其实藏着很多信息读懂了才能判断磁盘是健康还是虚惊。1.1 Filesystem、Size、Used、Avail、Use%、Mounted on分别代表什么随便找一台Linux机器执行df -h输出大概长这样Filesystem Size Used Avail Use% Mounted on /dev/sda2 98G 24G 69G 26% / /dev/sda1 511M 4.2M 507M 1% /boot/efi tmpfs 7.8G 0 7.8G 0% /dev/shm /dev/sdb1 458G 130G 305G 30% /data每一列的含义Filesystem对应的设备文件或伪文件系统比如/dev/sda2这种物理分区tmpfs这种内存文件系统。Size文件系统总容量。注意这里不是磁盘原始大小而是文件系统能用于数据存储的容量偶尔会小于分区大小因为块的预留、元数据等会占一部分。Used已经占用的空间。Avail还能用的空间已经扣掉了预留的部分。Use%Used / Size的百分比但有些文件系统不是按这个公式直接算比如ext4会考虑预留空间具体差异后面说。Mounted on挂载点也就是当前目录树的哪个入口对应这个文件系统。你会发现用df -h看到的Size是人类可读单位G、M都有不带-h时默认是KB或512字节块数值又长又难读。判断磁盘压力时始终要记住一个原则Avail才是你能写进去的保障Use%只是参考指标。1.2 特殊文件系统tmpfs、devtmpfs和overlay不算真正的磁盘df输出里经常有一堆你压根没碰过的名字比如tmpfs 24K 0 24K 0% /dev/shm tmpfs 793M 0 793M 0% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup devtmpfs 3.9G 0 3.9G 0% /dev overlay 98G 24G 69G 26% /docker/overlay2这些文件系统用的是内存不是物理磁盘。tmpfs会把内存的一部分当作临时存储devtmpfs是设备文件系统overlay是Docker的联合文件系统层。它们出现在df里是因为它们也有容量和使用率但实际占用的是RAM和内核缓存。所以排查磁盘有没有满时重点看真正挂在/、/home、/data这类目录下的物理分区别被tmpfs的0%或100%骗了。只有当你在df -h里看到Use%已经接近90%甚至100%且对应的挂载路径是你业务数据所在的位置才需要真正紧张起来。1.3 为什么有时候Use%会超过100%这个很少见但确实有。比如遇到文件系统异常、或者是某些NFS挂载、网络存储会有轻微波动。更多时候是你在df -h里看到99%但实际还能写入大概率是预留空间和reported量之间的差异。别慌先看Avail如果Avail还有几个G那就继续用如果Avail已经归零那就真的要紧盯进程了。2. 参数拆解df命令按场景选组合别只会敲 -hdf的基础用法很简单但实操里不同场景要用不同的参数。我常用的组合基本就这几种每种都有明确用途。2.1 常用参数及其适用场景参数作用适用场景-h人类可读单位G、M日常查看最常用-H按1000进制显示不是1024对齐设备的宣传容量时用-B 1M按固定大小块显示脚本解析时想统一单位-i查看inode使用情况排查inode耗尽的经典参数-T同时打印文件系统类型区分ext4、xfs、nfs等-t 类型只显示指定类型文件系统过滤ext4/xfs-x 类型排除指定类型文件系统不显示tmpfs等--total末尾追加总计行快速看所有分区合计--output字段自定义输出字段写监控脚本时用--sync先sync再统计对准确性要求较高时用表格只是索引真正要用好得知道每种参数背后解决的痛点。2.2 inode耗尽磁盘还有空间但什么都写不上去df -i的输出和普通df不太一样它把Size/Used/Avail换成了Inode总数、已用Inode和剩余InodeUsage%表示inode使用率。很多同学遇到过这种情况df -h显示还有几十G但创建文件时却提示No space left on device折腾半天发现是inode满了。inode是每个文件或目录的元数据载体它吃的是文件系统的固定区域不跟普通数据块共享。如果目录下小文件特别多比如缓存目录、邮件队列、Git对象库inode消耗速度就会远超容量。排查方法df -i如果某个挂载点下的IUse%接近100%优先处理小文件。最常见的解法是清理无用的文件、把多余小文件打包归档或者用find /某个目录 -type f | wc -l统计文件数量找出到底哪层堆积了太多文件。临时想腾出一点inode可以用find /data -type f -name *.tmp -delete这种定向清理。2.3 过滤文件系统类型只看真物理盘生产环境里df输出可能几十行混着tmpfs、nfs、cifs、overlay干扰判断。想只看本机的ext4和xfs分区怎么办df -hT -t ext4 -t xfs反过来想排除所有内存文件系统df -hTx tmpfs这种过滤在写告警脚本时特别有用。比如你只想监控真实磁盘分区的使用率不监控内存文件系统用-t ext4 -t xfs过滤后输出就干净多了。有些环境用的是LVM逻辑卷设备名可能叫/dev/mapper/vg-lv用-T看到类型是ext4或xfs一样能被过滤。2.4 自定义输出字段给脚本用的精准截取--output参数是很多运维脚本的隐藏利器。比如想只取文件系统、挂载点、使用率、可用空间df --outputsource,fstype,used,avail,pcent,target -h输出格式干净且不带多余的头部表格线脚本解析方便Filesystem Type Used Avail Use% Mounted on /dev/sda2 ext4 24G 69G 26% / /dev/sdb1 ext4 130G 305G 30% /data配合awk直接抓第5列来告警df --outputpcent,target -h /data | tail -1 | awk {print $1}这里注意--output后面的字段名有固定写法比如source、fstype、used、avail、pcent、target。你想批量检查多个目录时也可以一次传多个路径比如df -h /data /var /homedf会分别显示各自挂载点的信息这比df -h整屏输出更聚焦。3. 输出读不懂这些细节才是磁盘管理的命门初学者看到df输出以为就是一个容量表但实际运维里很多误判都源于对输出细节的理解偏差。下面几个点我踩过坑也看别人踩过。3.1 预留空间是怎么回事为什么df显示100%而实际还能写ext4和xfs都会预留一小部分块给root或系统关键进程使用默认是总量的5%ext4。所以在df -h里你会看到/dev/sda2的Use%已经到100%但Avail仍旧是0然而root用户还能往里面写入少量数据。这就是为什么有时df显示100%服务却还没完全瘫痪的原因之一。与之对应的另一个现象是df -h显示使用了90%但实际du -sh统计目录只有50%。因为df统计的是整个文件系统的已用block包括你删掉的文件、日志被进程持有的空间、还有一些元数据而du是逐个目录累加文件大小两个统计口径天然不同不能直接对比。我后面专门有一段排查流程会讲怎么应对这种偏差。3.2 挂载点边界df看到的是挂载视图不是磁盘分区物理关系比如你在/下挖了一个目录/mnt/data把另一块盘挂上去此时df -h /mnt/data显示的是那块盘的容量而不是根分区的容量。反过来如果/mnt/data下面的目录有程序在写数据但没挂载任何新设备那它占用的其实还是根分区空间。很多人看到df -h里某个目录快满了下意识以为是文件太大实际只是它有独立挂载点或者它所在的父分区本来就快满了。更常见的混淆是同一个设备被挂载到两个目录。比如/dev/sdb1 /data1 /dev/sdb1 /data2df里会显示两行相同的文件系统容量用同一个总量但使用率一样。如果这时你想精确到是/data1还是/data2在占用根本没法从df看出来得用du -sh /data1和du -sh /data2分别统计。3.3 容量单位不要混着用-h和-H差一个换算进制很多初学Linux的同学会忽略-h和-H的区别。-h是1024进制显示1G等于1024M-H是1000进制1G等于1000M。在硬盘厂商宣传容量和文件系统实际容量之间差异最多时能达到7%左右。判断磁盘使用率时务必统一用-h否则你在脚本里把结果跟某个阈值一比很可能会出现偏差。写监控脚本时最靠谱的是用-B 1M把单位固定成MB或者直接用--outputsize,used,avail并指定-kKB输出这样脚本里做数值计算才不会因为单位后缀不统一而出错。3.4 NFS和网络存储df在远程挂载上的表现不一样NFS挂载的容量和本地磁盘不同它返回的数字是NFS服务器上导出的文件系统参数挂载的时候不一定实时刷新。所以df -h /mnt/nfs显示的使用率可能比你实际看到的服务器容量滞后一段时间。验证NFS可用空间最好在服务器上直接跑df或者用nfsstat -m来更准确。不要完全信任客户端的df输出尤其是跨存储的情况。4. 实战场景快速定位磁盘空间不足的完整排查链路前面讲的是知识储备现在进入实操。假设你现在接到告警说服务器磁盘使用率超过95%你会怎么做我通常按下面几个步骤一步步缩小范围不绕弯子。4.1 第一步用 df -hT 看整体确定是哪个挂载点报警df -hT输出里可能有多个分区先看Use%最高的那个再通过挂载点判断是业务目、日志目录还是系统目录。比如看到/dev/sda2挂在/下使用率96%那大概率是操作系统盘快满了看到/dev/sdb1挂在/data下使用率98%那就需要进/data里排查具体目录。在排查前最好先记一下当前状态df -hT /tmp/df_before.txt这样做的好处是清理完数据后可以用同一份命令对比前后变化验证到底释放了多少空间。4.2 第二步区分真的文件占用大和已删除但还被进程占着当确认根分区快满之后我强烈不建议直接du -sh /去扫根目录因为根目录下还挂着/proc、/sys、/dev这些虚拟目录du会陷入大量无意义的遍历还可能卡住。更稳妥的做法是先切到最可能占空间的一级目录比如/var、/home、/tmp、/var/log分别统计du -sh /var /home /tmp /usr 2/dev/null | sort -rh | head哪一层大就再往里面一层一层拆直到找到具体文件。这个过程用du -h --max-depth1可以更细比如du -h --max-depth1 /var | sort -rh | head -15但扫着也不要太深一般三到五层就够定位到目录了。这里特别要提一个坑如果你用df看到已用空间始终降不下来但du统计目录加起来根本对不上很有可能是某个进程把一个日志文件删了但文件句柄还开着。这种文件在du里不存在却继续占据磁盘。排查方法lsof L1 | grep deleted找到deleted文件对应的进程PID然后再确认是哪个进程同时看一下它持有文件的Size列。如果是应用日志被删了但进程还在写通常重启该服务或让应用重新打开文件空间就会被释放。注意别在生产环境乱重启服务先和业务方确认再处理。4.3 第三步用 df 和 du 联合定位并写一个定时监控脚本整体排查完之后我建议还是要把看磁盘这件事变成自动化不要每次都人工跑命令。下面这个脚本可以平时挂在cron里每天跑一次#!/bin/bash THRESHOLD85 df -hT | awk NR1 { gsub(%,,$6); if ($6 THRESHOLD ($2ext4 || $2xfs)) { print $7, $6% used # 也可以在这里追加告警比如发送到webhook或邮件 } }脚本里NR1跳过第一行表头过滤ext4和xfs同时把百分比后面的%去掉再比较。如果你把THRESHOLD设成85那么任何物理分区到85%就会触发打印你可以后续再加上curl告警或logger记录。告警阈值通常分两级比如85%警告、95%紧急避免误报太多。同时我还会配一个数据收集命令每小时记录一次df的摘要方便后续回看趋势date %F %T /var/log/disk_usage.log df -hP / /data 2/dev/null /var/log/disk_usage.log-P参数是保证每行输出不跨行方便日志切割。4.4 第四步处理措施与预案扩容还是清数据如果df确认分区容量真的告警且清理不掉了就需要考虑扩容。在云服务器上通常是直接调整云盘容量然后用growpart和resize2fsext4或xfs_growfsxfs扩展文件系统。注意本地物理机上的LVM扩容路径是lvresize然后再扩展文件系统不同文件系统命令不一定兼容。扩容前记得备份数据同时在业务低峰操作。如果临时只能靠清数据优先清理内容如下逻辑日志文件/var/log下的一堆.log和.gz按需清理或轮转。包管理器缓存/var/cache/apt或/var/cache/yum。临时文件/tmp和/var/tmp。容器镜像残留docker system prune。旧内核/boot下旧内核文件但没经验的可以不做处理不当会把系统搞启动不起来。清完之后一定要再跑一次df -hT确认效果同时更新你的监控脚本基线。5. 学习df命令的一点心得不能只会看还得会判断到这里df命令的实操用法基本讲完了。最后分享几个我实际工作中形成的小习惯可能对你有帮助。我记得有一次公司内部服务频繁报警磁盘满了代码检查下来是日志轮转没生效但df显示已经写满。当时几个同事盯着du -sh /var/log看了半天日志目录才几个G后来用lsof L1 | grep deleted一查原来是某个Java进程把logback日志删了但句柄还打开着疯狂往已删除的文件里写。这个经验让我养成了一个固定的排查顺序先df -hT看整体再du看目录如果对不上就立刻lsof查被删除但仍被占用的文件。不要傻傻只靠单一命令下结论。另一个教训是不管磁盘使用率看着多高都要顺手看一眼-i的inode情况。有些场景下明明df -h还有几个G但就是创建不了文件因为inode已经满了。特别是使用rabbitMQ、Redis这类会创建大量小文件或消息队列目录的服务inode消耗极快。曾经我在一个大数据集群上遇到/data分区的df使用率才60%但任务全失败探查后发现inode已经100%那叫一个措手不及。后来每次磁盘排查我都会把df -h和df -i一起执行再决定下一步动作。还有一个容易被忽略的点是df命令本身不读取实时数值它读的是文件系统超级块里的统计数据。所以你修改文件、删除文件后df的数字不会立刻变化一般会延迟几秒甚至几十秒具体取决于系统负载和缓存的刷新策略。如果在脚本里频繁调用df做阈值判断要考虑到这种延迟避免清理文件后马上跑df发现没效果然后重复清理造成误判。稍微等几秒钟再查一次是值得的。另外df命令也适用于查看其他类Unix系统比如macOS和BSD参数和Linux基本一致但某些选项可能有差异。如果你日常工作在mac上排查远程Linux完全可以先在本地df -h熟悉输出格式再远程操作思路是通用的。最后我想强调一句df命令看着简单但它是磁盘管理的第一道门。真正遇到磁盘故障时能快速定位到哪个挂载点告警、哪个文件系统的类型是什么、预留空间有多大、是不是inode耗尽这些判断力都是靠平常反复演练得来的。建议你先在自己的虚拟机或服务器上把今天提到的参数挨个跑一遍把输出和注释对比着看遇到疑问再做实验验证慢慢就能形成肌肉记忆。
