df 命令需结合 -h、-t、-i 和过滤使用才能准确识别磁盘风险：use% 受保留空间和文件系统差异影响，tmpfs 的 100% 不代表磁盘满，inode 耗尽比空间不足更致命，且 total 行无实际意义。

df 是查看 Linux 磁盘使用率最直接的命令，但它默认输出的是块单位（1K-blocks），不加参数几乎没法快速判断哪块盘快满了。关键不是“能不能看”，而是“怎么看清、看准、不漏关键风险”。

df -h 显示人类可读的使用率，但别只信 Use% 这一列

执行 df -h 后，Use% 看似直观，但容易误判：

• Use% 计算基于“用户可用空间”，不包含 root 保留空间（通常是 5%，ext4 默认）。一块标称 95% 的盘，实际可能还有几百 MB 可写——但普通用户进程已无法写入
• 某些挂载点（如 /dev/shm、tmpfs）是内存虚拟文件系统，Use% 涨到 100% 不代表磁盘真满，只是内存吃紧
• 如果看到 / 或 /var 分区 Use% 超过 85%，必须立刻配合 du 追查，而不是等它到 95%

df -hT 查文件系统类型，避免误判 xfs/ext4/btrfs 行为差异

不同文件系统对空间预留、延迟分配、inode 管理策略不同，df -hT 能帮你提前预判风险点：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• xfs 默认不预留空间，Use% 接近 100% 时可能突然拒绝写入（尤其小文件密集场景）
• ext4 有 5% 保留块，df 显示 95% 时 root 还能写，但普通服务（如 nginx、mysql）通常以普通用户运行，实际已不可写
• btrfs 的 Use% 包含元数据开销，且支持配额，单看 df 容易低估真实压力
• 若发现 overlay 或 zfs 类型，说明在容器或 ZFS 环境中，df 显示的是上层挂载点，底层池空间需另查

df -i 查 inode 耗尽风险，比磁盘满更隐蔽也更致命

磁盘空间还有 20GB，但 df -i 显示 Use% 是 99%？那服务大概率已经挂了——尤其是日志轮转、邮件队列、临时上传目录这类小文件密集场景：

• df -i 输出中的 IUsed 和 IUse% 才是关键，IUse% > 90% 就该清理或扩容
• 常见罪魁：/var/log/journal（systemd-journald）、/var/spool/postfix、/tmp 下堆积的临时文件、Docker 容器未清理的 overlay 差分层
• find /path -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -nr | head -5 可快速定位哪个子目录生成最多 inode

df -h --total 加总行，但要注意 tmpfs 和 network fs 的干扰

df -h --total 末尾会多一行 total，看似方便，但这个“总”毫无业务意义：

• 它把 tmpfs（内存）、nfs（远程）、cgroup2（容器控制组）全加进去了，和物理磁盘容量完全无关
• 真正要盯的是 /、/home、/var、/data 这类本地块设备挂载点，建议用 df -h | grep '^/dev/' 过滤
• CentOS 7.9 等老系统中，df -h --total 在某些内核版本下会因 procfs 边界计算错误多加一行，数值不准，不如手动加

真正卡住系统的，往往不是“磁盘满”，而是某个分区的 inode 耗尽、某类 tmpfs 占用过高、或者 df 看不到的未挂载 LVM 逻辑卷空间碎片。别只盯着 Use% 数字，得结合挂载点语义、文件系统类型、inode 状态一起看。