1. 先搞清楚df在整套磁盘管理里的位置接手一台新服务器第一件事你会做什么我的答案永远是df -h。这个命令从我第一份运维工作用到现在可以说既古老又可靠。无论你是刚接触 Linux 的初学者还是每天要处理各种存储告警的运维df 都是绕不开的磁盘管理工具也是 Linux 命令大全里真正值得先掌握的几个命令之一。很多人会把 df、du、lsblk 三个命令混在一起其实它们看的维度完全不同。df 是站在文件系统层面看“整个挂载点还剩多少空间”数据来自内核的 statfs 调用也就是文件系统超级块里的统计信息所以速度极快不会像 du 那样逐目录扫描文件。du 是站在目录树层面统计“某个目录实际占了多少块”需要遍历大量文件。lsblk 则站在块设备层面列出的是磁盘、分区和它们之间的关系。简单类比df 看的是水表总读数du 是逐个水龙头去量流量lsblk 是检查水管和阀门的布局。这个区别在生产环境里非常重要。比如某台数据库服务器告警磁盘快满你第一反应应该是df -h看哪些挂载点快满了然后用 du 去定位哪个目录占用大最后用 lsblk 确认是不是某块盘的分区规划有问题。顺序一旦颠倒就容易在定位问题上浪费大量时间。df 还有一个优点就是它对权限几乎不敏感。普通用户也能看到文件系统容量不需要 sudo遇到挂载点权限受限、目录无法进入的情况df 依然能报告整个文件系统的使用状况。这也是我在处理“某个目录进不去但磁盘告警”时首选 df 的原因。提示如果只想看某个目录所在文件系统的容量直接df -h /path/to/dir即可df 会向上找到该目录所在的最顶层挂载点。这个用法在脚本里尤其常用。2. df命令的常用参数实用派最爱的8个选项2.1 为什么-h是默认第一选择初学者第一次执行 df会看到一堆数字Filesystem 1024-blocks Used Available Capacity Mounted on。这个“1024-blocks”其实是 1K 为单位的块数直接读很费劲。加参数 -h 后输出变成Size Used Avail Use% Mounted on单位会自动适配为 G 或 M一眼就能看懂容量。容器节点上查磁盘、日常排查告警我几乎每次都用df -h开头。如果你对单位有强迫症还有几个选择df -k强制以 1024 字节块显示df -m以 MB 显示df -B G以 GB 显示df --si则用 1000 进制1GB1000MB。注意不要混硬盘厂商标称的 1GB 是 1000^3 字节而 Linux 默认返回的 1G 是 1024^3 字节所以 df 显示的小于标称容量很正常这不是 bug。2.2 用-T看到文件系统类型用-i看到inode水位df -T会多打印一列 Type能瞬间告诉你这个挂载点是 ext4、xfs、nfs 还是 tmpfs。这个信息对定位问题极有价值。比如根分区是 xfs某个数据盘是 ext4两者扩容方式完全不同如果你看到/var/lib/docker挂的是 overlay说明容器存储是 Docker 的 overlay2 方案。df -i则是检查 inode 使用率很多人会忽略它。inode 是文件系统给每个文件/目录分配的索引节点一个分区即使有大量空闲空间如果 inode 用完了也会提示No space left on device。典型的“空间没满但写不进文件”的场景几乎都和 inode 耗尽有关。常见排查组合df -hT # 查看容量和文件系统类型 df -i /var/spool # 只看邮件队列所在分区的inode使用率 df -h /var/spool # 同一目录的容量占用情况如果df -i显示 Use% 到了接近 100%可以统计一下目录里到底有多少文件find / -xdev -type f | wc -l2.3 生产环境更常用的参数-l、-x、-P-l只显示本地文件系统-x tmpfs排除 tmpfs-t nfs只显示 NFS 等这些参数在告警脚本里非常关键。比如某台机器上有很多 Docker 的 tmpfs 挂载用df -h会有大量噪声配合grep -v tmpfs或者df -x tmpfs -h输出马上干净许多。-P是 POSIX 输出格式。默认 df 遇到特别长的挂载点名字可能会把同一行内容折成多行脚本用 awk 解析时会错位。加-P后一行对应一个文件系统字段固定。写监控脚本时我基本上是df -P /而不是df -h /。--sync会在读取前强制同步所有文件系统缓存保证数据一致性。代价是可能变慢仅在对一致性要求极高的场景下使用比如数据库备机巡检。下面这个表方便抄作业参数作用典型场景-h人类可读单位日常巡检-T显示文件系统类型判断磁盘格式-i显示inode使用率排查“有空间但写不进去”-l仅显示本地文件系统避免访问网络挂载点卡住-x type排除指定类型过滤tmpfs/overlay-PPOSIX稳定输出脚本解析--sync读取前同步数据一致性要求高-B size指定显示块大小需要特定单位3. 实操过程从日常巡检到自动告警3.1 新服务器上手第一件事快速盘点全盘我习惯登录一台新服务器后依次执行三条命令df -hT | grep -vE ^(tmpfs|devtmpfs|overlay) df -i / | tail -1 lsblk -f | grep -v loop第一条看整体容量以及文件系统类型哪块盘是系统盘、哪块是数据盘、是否已经挂载一目了然。第二条看系统盘 inode 是否健康。第三条看块设备结构比如 LVM 逻辑卷和物理设备对应关系便于后续扩容。这里故意用grep -vE过滤掉 tmpfs 和 overlay因为容器和内存盘太多会干扰对物理磁盘的判断。比如一台新交付的物理机输出可能是这样Filesystem Type Size Used Avail Use% Mounted on /dev/sda2 xfs 218G 9.9G 208G 5% / /dev/sda1 xfs 1014M 258M 756M 26% /boot /dev/mapper/vg_data-lv_data ext4 5.0T 1.2T 3.8T 25% /data看到 /data 是单独挂载的 ext4 逻辑卷就清楚这台机器是“系统盘数据盘分离”的规划。如果业务要往 /data 写数据后续扩容直接针对逻辑卷不会跟系统盘抢空间。3.2 5分钟写一个磁盘使用率监控脚本先说结论写监控脚本不要用df -h用df -P。因为 -h 输出的单位是动态的awk 解析容易翻车-P固定字段顺序每个文件系统一行最稳。下面是一个生产可用的简易脚本#!/usr/bin/env bash # 检查根分区使用率超过阈值发告警 THRESHOLD80 EMAILopsexample.com HOST$(hostname) USAGE$(df -P / | awk NR2 {print $5} | tr -d %) if [ $USAGE -gt $THRESHOLD ]; then df -hT | mail -s [Disk Alert] $HOST root usage ${USAGE}% $EMAIL fi关键点有两个。一是df -P / | awk NR2 {print $5}提取第 5 列也就是 Use%然后用tr -d %去掉百分号方便做数值比较。二是告警邮件正文用df -hT而不是df -P因为人是来看信息的人类可读输出更友好。如果公司用的不是邮件而是自定义监控平台通常只需要把告警消息通过 curl 推到 Webhook。也可以配合 cron 每 5 分钟执行一次*/5 * * * * /opt/scripts/disk_monitor.sh在多台服务器上建议把脚本统一放/opt/scripts/、日志统一放/var/log/disk_monitor/这样排障时不用换一台机器就要翻一遍历史。3.3 排查“空间够却写不进去”的隐藏原因这是我在实际工作中遇到最多的一种怪现象df -h显示还有 2G 可用但应用报磁盘满连临时文件都创建失败。大多数情况是 inode 用完了或者是残留的已删除文件还在被进程占用。先看 inodedf -i /如果 IUse% 接近 100%说明索引节点耗尽和文件数量有关和容量无关。此时要做的就是删文件而不是清空间。用find / -xdev -type f | wc -l统计文件数再用du -x --inodes / 2/dev/null | sort -k2 -n | tail定位哪个目录文件最多。再看占用但已删除的文件lsof L1 | head -30L1表示列出 link count 小于 1 的打开文件。这种文件已经从目录结构中删除但仍有进程持有句柄磁盘空间不会被释放。常见于日志轮转失败、数据库临时文件被删但进程还开着。处理方式是找到对应 PID让进程释放文件或重启服务。这个坑不熟悉的人会查半天实际上df和du对不上时十有八九是它。另外ext4 等文件系统默认保留 5% 的空间给 root 用df显示 100% 时其实还有预留空间可写只是普通用户用不了。可以用tune2fs -l /dev/sda1 | grep -i reserved查看预留比例必要时调小但我个人建议保留默认值它能在系统分区异常时将故障率降到最低。4. 常见问题与排查技巧实录4.1 df卡住不动是最大的坑某天你执行df -h光标闪烁半天不退出那就是遇到挂载目录连接问题了。最常见的是 NFS 挂载的远端存储失联本机内核在等待网络回归默认 timeout 可能是几分钟甚至更久。这种“卡住”对日常命令行操作是灾难对脚本更是雪上加霜因为脚本会一直挂在那一行。解决办法分三层第一层是在交互命令上加 timeout 包装比如timeout 10 df -h10 秒拿不到结果就放弃第二层是写监控脚本时用df -l只读本地文件系统从根本上绕开网络挂载第三层是修复挂载问题umount -l或umount -f强制卸载失联的 NFS 目录之后重新挂载或者调整挂载参数比如加soft,timeo50,retrans2让 NFS 的容错更快生效。对容器环境也要注意某些云盘的网络卷挂到宿主机后如果网络异常容器里执行df同样会卡。所以容器监控探针里尽量用df -l或者提前把 NFS 外的专用监控数据单独采集避免探针超时导致监控大面积误报。4.2 df显示100%但du却对不上前面提到已删除但被占用的文件这里再补充一个常见差异df 统计的是文件系统总大小和已用空间du 统计的是目录树中文件实际占用的字节数。两者天然存在差比如文件系统元数据、日志、预分配块、被隔离的坏块、快照差异等都不会出现在 du 里。所以 du 加起来略小于 df 是正常的如果差了几个 G重点检查lsof L1。还有一种情况是根分区的/proc、/sys等虚拟文件系统显示 0% 或者特别小这属于正常现象。tmpfs 则会把占用的内存显示成文件系统使用量比如/dev/shm。在容器里执行df -h看到 overlay 挂载显示的其实是宿主机文件系统的总容量因为 overlay 层位于宿主磁盘之上。这些“异常”输出都不是故障理解了本质就不会误判。4.3 监控脚本为什么隔三差五收到误报我曾经遇到过监控脚本偶尔收到磁盘 100% 告警人工登录看却只有 30%。排查了半天发现是某次登录时系统还没完成挂载df输出的临时文件系统计数被脚本解析错了。或者另一个原因脚本用df -h的时候单位 M 和 G 混排awk 拿到的 $5 不是预期列。预防误报的核心是标准化始终用df -P作为脚本输入告警后先df -hT确认状态再升级告警阈值用 N-2 而不是 N比如 85% 告警90% 升级留出操作缓冲。同时建议直接在脚本里排除不需要监控的挂载点比如/dev/shm、/run、/sys/fs/cgroup减少内部组件刷屏。4.4 厂商容量和df显示容量对不上要不要慌这个问题新手问得最多“我买的 1T 盘df 怎么才显示 931G”答案很简单厂商按 1000 进制标 1TB操作系统按 1024 进制算1TiB1.024TB所以显示自然少。这不是磁盘缩水也不是 df 算错。可以按df -B 1看一下精确字节数再对比硬件的标称字节数差别基本无非文件系统元数据和保留空间。记住这个规律后再遇到新盘挂载第一反应不是觉得被骗而是确认挂载参数、文件系统格式、是否加密、是否有 LVM 快照。用df结合lsblk -f基本能讲清楚所有空间去向。5. 写在最后的实操心得先给个我自己的顺序建议日常交互看df -hT脚本解析用df -P怀疑网络挂载卡住就timeout 10 df -h或者直接df -l遇到“空间没满报满”的怪问题第一反应查df -i和lsof L1。这一套流程基本能覆盖 80% 的磁盘故障排查场景。需求场景推荐命令日常看容量df -hT脚本解析df -P避免网络挂载卡住df -l排查inode耗尽df -i定位目录占用du -h --max-depth1查看已删除占用lsof L1强制卸载失联挂载umount -l 或 umount -f我在实际使用中还有一个习惯每次做磁盘扩容或迁移前先用df -hT和df -i各留一份快照到/var/log/disk_before_change.txt变更完成后对比一次。别小看这一步它能帮你快速确认新分区是否挂载成功、文件系统类型是否按预期、inode 水位是否正常。很多看起来“操作成功了”的扩容事故都是靠这种前后对照发现的。最后再分享一个小技巧如果你在排查某个进程为什么要读写大量数据可以用watch -n 2 df -h /data盯着目标分区观察两到三秒的变化幅度再加上lsof /data看哪个进程正持有文件句柄。磁盘管理这件事df 永远是最顺手的第一把钥匙。